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Abstract. The Hindley-Milner (HM) type system automatically infers 
the types at which polymorphic functions are used. In HM, the inferred 
types are unambiguous, and every expression has a principal type. How- 
ever, type inference is sometimes unwieldy or impossible, especially in 
the presence of type system extensions such as type classes and type- 
level functions. Even here, programmers cannot provide type arguments 
explicitly, as HM requires types to be invisible. 

We describe an extension to HM that allows for visible type applica- 
tion. Our extension requires a novel type inference algorithm, yet its 
declarative presentation is a simple extension to HM. We prove that our 
extended system is a conservative extension of HM and admits princi- 
pal types. We then extend our approach to a higher-rank type system 
with bidirectional type-checking. We have implemented this system in 
the Glasgow Haskell Compiler and show how our approach scales in the 
presence of complex type system features. 


1 Introduction 

The Hindley-Milner (HM) type system [7] Q2j US] achieves remarkable concision. 
While allowing a strong typing discipline, a program written in HM need not 
mention a single type. The brevity of HM comes at a cost, however: HM pro- 
grams must not mention a single type. While this rule has long been relaxed 
by allowing visible type annotations (and even requiring them for various type 
system extensions), it remains impossible for systems based on HM, such as 
OCaml and Haskell, to use visible type application when calling a polymorphic 
function 0 

This restriction makes sense in the HM type system, where visible type appli- 
cation is unnecessary, as all type instantiations can be determined via unification. 
Suppose the function id has type V a. a — ► a. If we wished to visibly instanti- 
ate the type variable a (in a version of HM extended with type annotations), 

1 Syntax elements appearing in a programmer’s source code are often called explicit , 
in contrast to implicit terms, which are inferred by the compiler. However, the im- 
plicit/explicit distinction is sometimes used to indicate whether terms are compu- 
tationally significant m- Our work to applies only to the inferred vs. programmer- 
specified distinction, so we use visible to refer to syntax elements appearing in source 
code. 
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Fig. 1 . The type systems studied in this paper 


we could write the expression (id :: Int — ► Int). This annotation forces the type 
checker to unify the provided type Int — >• Int with the type a — >• a, concluding 
that type a should be instantiated with Int. 

However, this annotation is a roundabout way of providing information to 
the type checker. It would be much more direct if programmers could provide 
type arguments directly, writing the expression id @lnt instead. 

Why do we want visible type application? In a language like Haskell - as 
implemented by the Glasgow Haskell Compiler (GHC) - which is based on HM 
but extends it significantly, we find two main benefits. 

Type instantiation cannot always be determined by unification. Some Haskell 
features, such as type classes [21] and GHC’s type families 0 01 E], do not 
allow the type checker to unambiguously determine type arguments from an an- 
notation. The current workaround for this issue is the Proxy type which clutters 
implementations and requires careful foresight by library designers. Visible type 
application improves such code. (See Sect. §) 

It is sometimes painful to determine instantiations via type annotations. Even 
when type arguments can be determined from an annotation, this mechanism 
is still not always friendly to developers. For example, the variable to instan- 
tiate could appear multiple times in the type, leading to a long annotation. 
Partial type signatures help (29], but they don’t completely solve the problem. 
Appendix |A| contains an example of this issue. 

Although the idea seems straightforward, adding visible type applications to 
the HM type system requires care, as we describe in Sect. [3] In particular, we 
observe that we can allow visible type application only at certain types: those 
with specified type quantification. These types are known to the programmer via 
type annotation. Such types may be instantiated visibly. Their instantiations 
may also be inferred as usual, should the programmer omit type applications. 

This paper presents a systematic study of the integration of visible type 
application within the HM typing discipline. In particular, the contributions of 
this paper are the four novel type systems (HMV, V, SB, B), summarized in 

Fig-13 

— System HMV extends the declarative HM type system with a single, straight- 
forward new rule for visible type application. In support of this feature, it 
also includes two other extensions: scoped type variables and a distinction 
between specified and generalized type quantification. The importance of this 
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system is that it demonstrates that visible type application can be added or- 
thogonally to the HM type system, an observation that we found obvious 
only in hindsight. 

— System V is a syntax-directed version of HMV. This type system directly 
corresponds to a type inference algorithm, called V. We show that although 
Algorithm V works differently than Algorithm W [S] , it retains the ability to 
calculate principal types. The key insight is that we can delay the instantia- 
tion of type variables until necessary. We prove that System V is sound and 
complete with respect to HMV, and that Algorithm V is sound and complete 
with respect for System V. These results show the principal types property 
for HMV. 

— System SB is a syntax-directed bidirectional type system with higher-rank 
types. In extending GHC with visible type application, we were required 
to consider the interactions of System V with all of the many type system 
extensions featured in GHC. Most interactions are orthogonal, as expected 
from the design of V. However, GHC’s extension to support higher-rank 
types [23j changes its type inference algorithm to be bidirectional. System 
SB shows that our approach in designing System V extends to a bidirectional 
system in a very straightforward way. System SB’s role in this paper is 
twofold: to show how our approach to visible type application meshes well 
with type system extensions, and to be the basis for our implementation in 
GHC. 

— System B is a novel, simple declarative specification of System B. We prove 
that System SB is sound and complete with respect to System B. A similar 
declarative specification was not present in prior work |23i ; this paper shows 
that an HM-style presentation is possible even in the case of higher-rank 
systems. 

Our visible type application extension is available^] We expect it to be in- 
cluded in the next major release of GHC. Appendix [B] describes this implemen- 
tation and elaborates on interactions between our algorithm and other features 
of GHC. 

The Appendices of this paper contain extended examples and detailed proofs 
of the properties studied about each of the systems. 

However, before we discuss how to extend HM type systems with visible 
type application, we first elaborate on why we would like this feature in the first 
place. The next section briefly describes situations in Haskell where visible type 
applications would benefit programmers. 


2 Example of visible type application 

When a Haskell library author wishes to give a client the ability to control type 
variable instantiation, the current workaround is the standard library’s Proxy 
type. 

2 See https://github.com/goldfirere/ghc, at the esop-2016 tag 
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data Proxy a = Proxy 

However, as we shall see, programming with Proxy is noisy and painfully indirect. 
With built-in visible type application, these examples are streamlined and easier 
to work with j^] In the following example and throughout this paper, unadorned 
code blocks are accepted by GHC 7.10, blocks with a solid gray bar at the 
left are ill- typed, and blocks with a gray background are accepted only by our 
implementation of visible type application. 


Resolving type class ambiguity Suppose a programmer wished to nor- 
malize the representation of expression text by running it through a parser 
and then pretty printer. The normalize function below maps the string 
"7 - 1 * 0 + 3 / 3" to " ((7 - (1 * 0)) + (3 / 3))", resolving prece- 
dence and making the meaning clearj^] 

normalize :: String — > String 

normalize x = show ((read :: String — >■ Expr) x) 

However, the designer of this function can’t make it polymorphic in a straight- 
forward way. Adding a polymorphic type signature results in an ambiguous type, 
which GHC rightly rejects. 

normalizePoly :: V a. (Show a, Read a) => String — >■ String 
normalizePoly x = show ((read :: String — > a) x) 

Instead, the programmer must add a Proxy argument, which is never eval- 
uated, to allow clients of this polymorphic function to specify the parser and 
pretty-printer to use 

normalizeProxy :: V a. (Show a, Read a) 

=> Proxy a — > String — » String 
normalizeProxy _ x = show ((read :: String — > a) x) 
normalizeExpr :: String — > String 

normalizeExpr = normalizeProxy (Proxy :: Proxy Expr) 

With visible type application, we can write these two functions more di- 
rectly 0 

3 Visible type application has been a GHC feature request since 2011. See https: 
/ /ghc .haskell . org/trac/ghc/ticket/5296 
■* This example uses the following functions from the standard library, 

show :: Show a => a — » String 
read :: Read a => String — > a 

as well as user-defined instances of the Show and Read classes for the type Expr. 

5 Our new extension TypeApplications implies the extension AllowAmbiguousTypes, 
which allows our updated normalize definition to be accepted. 
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normalize :: V a. ( Show a , Read a) => String — ► String 
normalize x = show ( read @a x) 
normalizeExpr :: String — > String 
normalizeExpr = normalize @Expr 

Although the show / read ambiguity is somewhat contrived in this case, proxies 
are indeed useful in more sophisticated APIs. For example, suppose a library 
design would like to allow users of the library to choose the representation of an 
internal data structure to best meet the needs of their application. If the type 
of that data structure is not included in the input and output types of the API, 
then a Proxy argument is a way to give this flexibility to clients)^] 


Other examples More practical examples of the need for visible type appli- 
cation require a fair amount of build-up to motivate the need for the intricate 
types involved. We have included two larger examples in App. [A] One builds 
from recent work on deferring constraints until runtime [5] and the other on 
translating a dependently typed program in Agda m into Haskell. 

3 Our approach to visible type application 

Visible type application seems like a straightforward extension, but adding this 
feature - both to GHC and to the HM type system that it is based on - turned 
out to be more difficult and interesting than we first anticipated. In particular, 
we encountered two significant problems when trying to extend the HM type 
system with visible type application. 


3.1 Just what are the type parameters? 

The first problem is that it is not always clear what the type parameters to a 
polymorphic function are! 

One aspect of the HM type system is that it permits expressions to be as- 
signed any number of isomorphic types. For example, the identity function for 
pairs, 

pid (x, y) = (x,y) 

can be assigned any of the following types: 

(1) V a 6. (a, b ) — > (a, b) 

(2) V a 6. (£>, a) — > ( b , a) 

(3) V c a b. (a, b) — > (a, b) 

6 See http : / /stackoverf low. com/questions/27044209/haskell- why- use -proxy 
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Class constraints don’t have a fixed ordering in types, and it is possible that a type 
variable is mentioned only in a constraint. Which of the following is preferred? 

V r m w a. ( MonadReader r m , MonadWriter w m) => a — > m a 

V w m r a. ( MonadWriter w m , MonadReader r m) => a — » m a 

Equality constraints and GADTs can add new quantified variables. Should we prefer 
the type V a. a — > a or the equivalent type V a b. (a ~ b) a — ¥ fa? 

Type abbreviations mean that quantifying variables as they appear can be ambigu- 
ous without also specifying how type abbreviations are used and when they are 
expanded. Suppose 

type Phantom a = Int 
type Swap a b = (b, a) 

Should we prefer V a b. Swap a b Int or V b a. Swap a b —t Int ? Similarly, should 
we prefer V a. Phantom a — ¥ Int or Int — » Inti 


Fig. 2. Why specified polytypes? 


All of these types are principal; no type above is more general than any other. 
However, the type of the expression, 

pid @lnt @Bool 

is very different depending on which “equivalent” type is chosen for pid : 

(Int, Bool) — t (Int, Bool) — pid has type (1) 

(Bool, Int) — > (Bool, Int) — pid has type (2) 

V b. (Bool, b) — > (Bool, b) — pid has type (3) 

Of course, there are ad hoc mechanisms for resolving this ambiguity. We 
could try to designate one of the above types (1-3) as the real principal type 
for pid, perhaps by disallowing the quantification of unused variables (ruling 
out type 3 above) or by enforcing an ordering on how variables are quantified 
(preferring type 1 over type 2 above). Our goal would be to make sure that 

each expression has a unique principal type, with respect to its quantified type 

variables. However, in the context of the full Haskell language, this strategy 
fails. There are just too many ways that types that are not a-equivalent can be 
considered equivalent by HM. See Fig.[2]for a list of language features that cause 
difficulties. 

In the end, although it may be possible to resolve all of these ambiguities, we 
prefer not to. That approach leads to a system that is fragile (a new extension 
could break the requirement that principal types are unique up to a-equivalence) , 
difficult to explain to programmers (who must be able to determine which type 
is principal) and difficult to reason about. 

Our solution: specified polytypes Therefore, our system is designed around 
the following principle: 
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Only “ specified ” type parameters can be instantiated via explicit type ap- 
plications. 

In other words, we allow visible type application to instantiate a polytype only 
when both of the following are true: 

1. The polytype is already fixed: constraint solving will give us no more infor- 
mation about the type. 

2. The programmer may reasonably know what the type is. 

In practice, these guidelines mean that visible type application is available 
only on types that are given by an annotation. These restrictions follow in a long 
line of work requiring more user annotations to support more advanced type sys- 
tem features 0ili. We refer to variables quantified in type annotations as 
specified variables, distinct from compiler-generated quantified variables, which 
we call generalized variables. 


Imported functions A natural question that arises here is how imported func- 
tions are handled. All imported functions meet the two criteria above. Their 
types are fixed, and the programmer can learn their types (via documentation 
or queries in an interactive interpreter). Yet, there is something unsatisfactory 
about allowing all imported functions to have specified type parameters: the or- 
der of the type parameters may still be determined by the compiler, if an inferred 
type is similar to any of the examples in Fig. [2] 

In these cases, the choice of type variable ordering seems very fragile and hard 
for a compiler to make guarantees about. We do not want the order changing 
between runs of the compiler, or even between minor revisions of the compiler. 
We thus have decided: 

Type parameters from user-supplied types of imported functions are spec- 
ified; type parameters of other imported functions are generalized. 

A stricter possibility is to allow specified type variables to arise only when 
the exporting module explicitly puts V a b. ... in a type signature. However, our 
design decision strikes a middle ground between availability of the visible type 
inference feature and predictability. 

3.2 What is the specification of the type system? 

We don’t want to extend just the type inference algorithm that GHC uses. We 
would also like to extend its specification, which is rooted in HM. This way, we 
will have a concise description (and better understanding) of what programs 
type check, and a simple way to reason about the properties of the type system. 

Our first attempt to add type application to GHC was based on our under- 
standing of Algorithm W, the standard algorithm for HM type inference. This 
algorithm instantiates polymorphic functions only at occurrences of variables. 
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So, it seems that the only new form we need to allow is a visible type right after 
variable occurrences: 

x @n ... @t„ 

However, this extension is not very robust to code refactoring. For example, 
it is not closed under substitution. If type application is only allowed at vari- 
ables, then we can’t substitute for this variable and expect the code to still type 
check. Therefore our algorithm should allow visible type applications at other 
expression forms. But where else makes sense? 

One place that seems sensible to allow a type instantiation is after a poly- 
morphic type annotation (such an annotation certainly specifies the type of the 
expression) : 

(Ax — > x :: V a b. (a, b) — ► (a, b)) @lnt 

Likewise, if we refactor this term as below, we should also allow a visible instan- 
tiation after a letQ 

(let y = ((Ax — > x) :: V a b. (a, b) — ► (a, b)) in y) @lnt 

However, how do we know that we have identified all sites where visible type 
applications should be allowed? Furthermore, we may have identified them all 
for core HM, but what happens when we go to the full language of GHC, which 
includes features that may expose new potential sites? 

One way to think about this issue in a principled way is to develop a compo- 
sitional specification of the type system, which allows type application for any 
expression that can be assigned a polytype. Then, if we develop an algorithm 
that is complete with respect to this specification, we will know that we have 
allowed type applications in all of the appropriate places. 


Our solution: lazy instantiation for specified polytypes This reasoning, 
inspired by thinking about how to extend the declarative specification of the HM 
type system, has lead us to develop a new approach to HM type inference. This 
algorithm, which we call Algorithm V, is based on the following design principle: 

Delay instantiation of “ specified ” type parameters until absolutely neces- 
sary. 

Although Algorithm W instantiates all polytypes immediately, it need not 
do so. In fact, it is possible to develop a sound and complete alternative imple- 
mentation of the HM type system that does not do this immediate instantiation. 
Instead, instantiation is done only on demand, such as when a polymorphic func- 
tion is applied to arguments. Lazy instantiation has been used in type inference 

1 In fact, the Haskell 2010 Report |15| defines type annotations by expanding to a 
let-declaration with a signature. 
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HM 

Metavariables: x, y term variables 
a , b, c type variables 
n numeric literals 

e ::= x \ Xx. e \ ei e 2 expressions 
[ n | let x = ei in e 2 
r ::= a | n — > T2 \ Int monotypes 
cr ::=V{a}.T type schemes 

r ::= • | r,x\a contexts 


HMV 


This grammar extends HM: 


e ::= ... e @t 

(Aa.e 

v ) expressions 

t ::= ... 


monotypes 

v ::= Va. r 


spec, polytypes 

a ::= V{a}. v 


type schemes 

r ::=■ | r,x:a 

r. a 

contexts 


We write (e : v) to mean (A - .e : v) and ftv(a) 
to be the set of type variables free in a. 


Fig. 3. Grammars for Systems HM and HMV 


before m and may be folklore; however this work contains the first proof that 
it can be used to implement the HM type system. 

In the next section, we give this algorithm a simple specification, presented 
as a small extension of HM’s existing declarative specification. We then make 
the details of our algorithm precise by giving a syntax-directed account of the 
type system, characterizing where lazy instantiations actually must occur during 
type checking. 


4 HM with visible type application 

To make our ideas precise, we next review the declarative specification of the HM 
type system [3 [T5] (which we call System HM) , and then show how to extend 
this specification with visible type arguments. 


4.1 System HM 

The grammar of System HM is shown in Fig. [3} The expression language com- 
prises the Curry-style typed A-calculus with the addition of numeric literals (of 
type Int) and let-expressions. Monotypes are standard, but we quantify over a 
possibly-empty set of type variables in type schemes. Here, we diverge from stan- 
dard notation and write these type variables in braces to emphasize that they 
should be considered order-independent. We sometimes write r for the type 
scheme V{ }. r with an empty set of quantified variables, and write V{a}.V{6}.r 
to mean V{a, 6}.r. Here - and throughout this paper - we liberally use the 
Barendregt convention that bound variables are always distinct from free vari- 
ables. 

The declarative typing rules for System HM appear in Fig. [4j (The figures 
on HM also include the definition for our extended system, called System HMV, 


described in Sect. 4.2 ) System HM is not syntax-directed; rules HM_Gen and 


HM_Sub can apply anywhere. 

So that we can better compare this system with others in the paper, we 
make two small changes to the standard HM rules. Neither of these changes are 
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E e : a Typing rules for System HM 
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HMV Annot 
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Type well-formedness 

ftv{v) C E 


Ul[r/0l] <hmv w 2 

o 2 £ /ti)(V{ai}. Vi) 
V{0l}. Vl <hmv V{a 2 }. V2 


HMV InstG 


Ty Scoped 


Eh v 

Fig. 4. Typing rules for Systems HM and HMV 


substantial; our version types the same programs as the original. First, we allow 
the type of a let expression to be a polytype a, instead of restricting it to be a 
monotype r. (We discuss this change further in Sect. 5.2 ) Second, we replace 
the usual instantiation rule with HM_Sub. This rule allows the type of any 
expression to be to converted to any less general type in one step (as determined 
by the subsumption relation cti <h m < 72 ). Note that in rule HM_InstG the lists 
of variables a\ and a 2 need not be the same length. 
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V{a, 6}. a 
Va, b. a 
Va, b. a 
Va, b. a 
Va, b. a 

Va, b. a 
V{a}. a 


b £hmv V{a}. ^ t a 
<hm» Int — » Int 
b ^hmv Va. a — ^ Int 
b <hmv V{a, 6}. a — >• b 
b <hm» V{b}. Int — > b 

b 6m» V6. Int — >■ 6 
a 6m» Va. a — > a 


Works the same as <h m for type schemes 
Can instantiate specified vars 
Can instantiate only a tail of the specified vars 
Variables can be regeneralized 
Right-to-left nature of HMV_InstS 
forces regeneralization 

Known vars are instantiated from the right, 
never the left 

Specified quantification is more general 
than generalized quantification 


Fig. 5. Examples of HMV subsumption relation 


4.2 System HMV: HM with visible types 

System HMV is an extension of System HM, adding visible type application. A 
key detail in its design is its separation of specified type variables from those 
arising from generalization, as initially explored in Sect. |3.1[ Types may be 
generalized at any time in HMV, quantifying over a variable free in a type but 
not free in the typing context. The type variable generalized in this manner is 
not specified, as the generalization takes place absent any direction from the 
programmer. By contrast, a type variable mentioned in a type annotation is 
specified, precisely because it is written in the program text. 


Grammar The grammar of System HMV appears in Fig. [3] The type language 
is enhanced with a new intermediate form v that quantifies over an ordered list of 
type variables. This form sits between type schemes and monotypes; as contain 
vs, which then contain rsJ^Thus the full form of a type scheme a is V{ cz} , b. r, 
including both a set of generalized variables {a} and a list of specified variables 
b. Note that order never matters for generalized variables (they are in a set) 
while order does certainly matter for specified variables (the list specifies their 
order). We say that v is the metavariable for specified polytypes , distinct from 
type schemes a. 

Expressions in HMV include two new forms: e @t instantiates a specified 
type variable with a monotype r, while (Aa.e : v) allows us to bind scoped type 
variables and put a type annotation on an expression. The type annotation is a 
specified polytype v. We do not allow annotation by type schemes a , with quan- 
tified generalized variables: if the user writes the type, all quantified variables 
are considered specified. 

8 The grammar for System HMV redefines several metavariables. These metavariables 
then have (slightly) different meanings in different sections of this paper, but disam- 
biguation should be clear from context. In analysis relating systems with different 
grammars (for example, in Lemma [l]), the more restrictive grammar takes prece- 
dence. 
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Typing contexts r in HMV are enhanced with the ability to store type vari- 
ables. This feature is used to implement scoped type variables, where any vari- 
ables bound by a A in a type annotation are available to use within the annotated 
expression. 


Typing rules The type system of HMV includes all of the rules of HM plus 
the new rules and relation shown at the bottom of Fig. [4] The HMV rules 
inherited from System HM are modified to recur back to System HMV relations: 
in effect, replace all hm subscripts with hmv subscripts. Note, in particular, rule 
HM_SUB; in System HMV, this rule refers to the <j\ <hmv 02 relation, described 
below. 

The most important addition to this type system is HMV_TApp, which 
enables visible type application when the type of the expression is quantified 
over a specified type variable. 

A type annotation (A a.e : v), typed with HMV_Annot, allows an expres- 
sion to be assigned a specified polytype. We require the specified polytype to 
have the form Va, 6.r; that is, a prefix of the specified polytype’s quantified 
variables must be the type variables scoped in the expression. This restriction 
fixes the relationship between the scoped type variables and the assigned spec- 
ified polytype. The inner expression e is then checked at type r, with the type 
variables a (but not the b) in scope. Of course, in the T, a e : r premise, 
the variables a and b still (perhaps) appear in r, but they are no longer quan- 
tified. We call such variables skolems and say that skolemizing v yields r. In 
effect, these variables form new type constants when type-checking e. When the 
expression e has type r, we know that e cannot make any assumptions about 
the skolems a, b and that we can assign e the type Vv, b.r. This is, in effect, 
specified generalization. 

The relation ay <hmv 02 (Fig. [4]) implements subsumption for System HMV. 
The intuition is that, if a ± <h mv 02) then an expression of type tri can be used 
wherever one of type <r 2 is expected. For type schemes, the standard notion of o\ 
being a more general type than er 2 is sufficient. However for specified polytypes, 
we must be more cautious. 

Suppose an expression x @ri @t 2 type checks, where x has type Va, b. V\. The 
subsumption rule means that we can arbitrarily change the type of x to some 
v, as long as v <h mv Va, b. v\. Therefore, v must be of the form Va, b. v 2 so that 
x @Ti @r 2 will continue to instantiate a with ly and b with r 2 . Accordingly, we 
cannot, say, allow subsumption to reorder the specified variables. 

However, it is safe to allow some instantiation of specified variables as part of 
subsumption, as in rule HMV_InstS. Examine this rule closely: it instantiates 
variables from the right This odd-looking design choice is critical. Continuing 
the example above, v could also be of the form \/a,b,c.v 3. In this case, the 
additional specified variable c causes no trouble - it need not be instantiated 
by a visible application. But we cannot allow instantiation left-to-right as that 
would allow the visible type arguments to skip instantiating a or b. 

Further examples illustrating <hmv appear in Fig. [5j 
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4.3 Properties of System HMV 

We wish System HMV to be a conservative extension of System HM. That is, 
any expression that is well-typed in HM should remain well-typed in HMV, and 
any expression not well-typed in HM (but written in the HM subset of HMV) 
should also not be well- typed in HMV. 

Lemma 1 (Conservative Extension for HMV). Suppose r and e are both 
expressible in HM; that is, they do not include any type instantiations, type 
annotations, scoped type variables, or specified polytypes. Then, T \^ m e : cr if 
and only if T hp, mv e : a. 

This property follows directly from the definition of HMV as an extension of 
HM. Note, in particular, that no HM typing rule is changed in HMV and that the 
<hmv relation contains < hm ; furthermore, the new rules all require constructs 
not found in HM. 

We also wish to know that making generalized variables into specified vari- 
ables does not disrupt types: 

Lemma 2 (Extra knowledge is harmless). If T, X'M{a}. r ly mv e : a, then 
T, x-Ma. t fh mv e : a. 

This property follows directly from a context generalization lemma, stated and 
proven in App. 0 which states that we can generalize types in the context 
without affecting typability. Note that Va. r <hmv V{a}.r. 

In practical terms, Lemma [2] means that if an expression contains let x = 
e\ in e 2 , and the programmer figures out the type assigned to x (say, V{7 j}.t) 
and then includes that type in an annotation (as let x = (ei : Va. t) in e 2 ), the 
outer expression’s type does not then change. 

However, note that, by design, context generalization is not as flexible for 
specified polytypes as it is for type schemes. In other words, suppose the following 
expression type-checks. 

let x = ((Ay — >■ y) :: V a b. (a, b) — > (a, b )) in ... 

The programmer cannot then replace the type annotation with the type V a. a — > 
a, because x may be used with visible type applications. This behavior may 
be surprising, but it follows directly from the fact that V a. a — > a ^mv 
V a 6. (a, b) — > (a, b). 

Finally, we would also like to show that a system with visible types retains 
the principal types property, defined with respect to the enhanced subsumption 
relation <j\ <hmv ai- 

Theorem 3 (Principal types for HMV). For all terms e well-typed in a 
context r , there exists a type scheme cr p such that T if,,™ e : a p and, for all a 
such that r ffjpny e . (t , tx p h mv er . 

Before we can prove this, we first must show how to extend HM’s type infer- 
ence algorithm (Algorithm W [5]) to include visible type application. Once we 
do so, we can prove that this new algorithm always computes principal types. 
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F t e : r Typing rules for System C 



s:V{ a}.r € F r, x:ti b e : T2 

„ , r _ C VAR —4; 



Fb e ie2 :t 2 ~ F bn 


F b n '■ Int 


C Int 



F b let x = ei in e 2 : t 2 


F b: en e : a Generalization for System C 


a = ftv(r) \ ftv(F) F b e : t 
rf" e :V{a}.r 


C Gen 


We lift ftv to work on contexts: ftv(x:a ) = (J; ftv(<Ti). 


Fig. 6. Syntax-directed version of the HM type system 


5 Syntax-directed versions of HM and HMV 

The type systems in the previous section declare when programs are well-formed, 
but they are fairly far removed from an algorithm. In particular, the rules 
HM_Gen and HM_Sub can appear at any point in a typing derivation. 


5.1 System C 

We can explain the HM type system in a more algorithmic manner by using a 
syntax-directed specification, called System C, in Fig. [6] This version of the type 
system, derived from Clement et al. [3, clarifies exactly where generalization and 
instantiation occur during type checking. Notably, instantiation occurs only at 
the usage of a variable, and generalization occurs only at a let-binding. These 
rules are syntax-directed because the conclusion of each rule in the main judg- 
ment r e : t is syntactically distinct. Thus, from the shape of an expression, 
we can determine the shape of its typing derivation. 

However, the judgment T ^ e : r is still not quite an algorithm: it makes non- 
deterministic guesses. For example, in the rule C_Abs, the type n is guessed; 
there is no indication in the expression what the choice for n should be. The 
advantage of studying a syntax-directed system such as System C is that doing 
so separates concerns: System C fixes the structure of the typing derivation (and 
of any implementation) while leaving monotype-guessing as a separate problem. 
Algorithm W deduces the monotypes via unification, but a constraint-based 
approach BUIS] would also work. 
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E b e : r Monotype checking for System V 

r k ei : Ti 


E, x:ti k e '■ T2 
F b A®. e : n — > to 


V Abs 


T2 


El; e2 : ri 


E b n : Int ~ 


V Int 


E b ei e 2 : t 2 

E £ e : Vo. r 
no other rule matches . 
E b e : t[t/o] 


V App 


-V InstS 


E b e : w 


Specified polytype checking for System V 


s:V{a}.u G E E If™ ei : cri F,x:ai b e2 : V2 

r V Var — _ . E 1 v let 


E 1J x : v[t/ a] 

r hr 

E Ij e : Ma. v 
F ^ e @r : w[t/ a] 


V TApp 


E 1J let x = ei in e 2 : V 2 

F l- v v = Va, b. r 
E, a b e : r 

E hj) (Aa.e : v) : v 


V Annot 


E b e : t 
no other rule matches . 


E It; e : r 


-V Mono 


re 


Generalization for System V 

a = ftv(v)\ftv{r) r^ew 


V Gen 


re n e : V{a}. v 

Contexts E now contain type variables. We thus redefine ftv(x:a, a) = aU (J 
Fig. 7. Typing rules for System V 


5.2 System V: Syntax-directed visible types 

Just as System C is a syntax-directed version of HM, we can also define System 
V, a syntax-directed version of HMV (Fig. [7]). However, although we could de- 
fine HMV by a small addition to HM (two new rules, plus subsumption), the 
difference between System C and System V is more significant. 

Like System C, System V uses multiple judgments to restrict where general- 
ization and instantiation can occur. In particular, the system allows an expres- 
sion to have a type scheme only as a result of generalization (using the judgment 
e : a). Generalization is, once again, available only in let-expressions. 

However, the main difference that enables visible type annotation is the sep- 
aration of the main typing judgment into two: E b e : t and E ^ e : v. The key 
idea is that, sometimes, we need to be lazy about instantiating specified type 
variables so that the programmer has a chance to add a visible instantiation. 
Therefore, the system splits the rules into a judgment b that requires e to have 
a monotype, and those in that can retain quantification in a specified polytype. 
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The first set of rules in Fig. [ 7 ] as before, infers a monotype for the expression. 
The premises of the rule V_ Abs uses this judgment, for example, to require that 
the body of an abstraction have a monotype. All expressions can be assigned 
a monotype; if the first three rules do not apply, the last rule V_InstS infers 
a polytype instead, then instantiates it to yield a monotype. Because implicit 
instantiation happens all at once in this rule, we do not need to worry about 
instantiating specified variables out of order, as we did in System HMV. 

The second set of rules (the judgment) allows e to be assigned a specified 
polytype. Note that the premise of rule V_TApp uses this judgment. 

Rule V_Var is like rule C_VAR: both look up a variable in the environ- 
ment and instantiate its generalized quantified variables. The difference is that 
C_ Var’s types can contain only generalized variables; System V’s types can 
have specified variables after the generalized ones. Yet we instantiate only the 
generalized ones in the V_Var rule, lazily preserving the specified ones. 

Rule V_Let is likewise similar to C_Let. The only difference is that the 
result type is not restricted to be a monotype. By putting V_Let in the 
judgment and returning a specified poly type, we allow the following judgment 
to hold: 

• ^ (let x = (Ay. y : Va. a — ► a) in x) @lnt : Int — ► Int 

The expression above would be ill-typed in a system that restricted the result of 
a let-expression to be a monotype. It is for this reason that we altered System 
HM to include a polytype in its HM_Let rule, for consistency with HMV. 

Rule V_Annot is identical to rule HMV_Annot. It uses the 1^ judgment 
in its premise to force instantiation of all quantified type variables before regener- 
alizing to the specified polytype v. In this way, the V_Annot rule is effectively 
able to reorder specified variables. Here, reordering is acceptable, precisely be- 
cause it is user-directed. 

Finally, if an expression form cannot yield a specified polytype, rule 
V_Mono delegates to to find a monotype for the expression. 

5.3 Relating System V to System HMV 

Systems HMV and V are equivalent; they type check the same set of expressions. 
We prove this correspondence using the following two theorems. 

Theorem 4 (Soundness of V against HMV). 

1. If r ^ e : t, then T lp; mv e : r. 

2. If r ^ e : v, then r fh mv e : v. 

3. //Ttf n e : a, then T k mv e : a. 

Theorem 5 (Completeness of V against HMV). If T fh mv e : a, then there 
exists a' such that r \^ en e : a' where cr' <hmv cr. 

The proofs of these theorems appear in App. [D] 

Having established the equivalence of System V with System HMV, we can 
note that Lemma[2] (“Extra knowledge is harmless”) carries over from HMV to V. 
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This property is quite interesting in the context of System V. It says that a typing 
context where all type variables are specified admits all the same expressions as 
one where some type variables are generalized. In System V, however, specified 
and generalized variables are instantiated via different mechanisms, so this is a 
powerful theorem indeed. 

It is mechanical to go from the statement of System V in Fig. [ 7 ] to an algo- 
rithm. In App.[E] we define Algorithm V which implements System V, analogous 
to Algorithm W which implements System C. We then prove that Algorithm V 
is sound and complete with respect to System V and that Algorithm V finds 
principal types. Linking the pieces together gives us the proof of the princi- 
pal types property for System HMV (Theorem [3]). Furthermore, Algorithm V is 
guaranteed to terminate, yielding this theorem: 

Theorem 6. Type-checking System V is decidable. 

6 Higher-rank type systems 

We now extend the design of System HMV to include higher-rank polymor- 
phism m- This allows function parameters to be used at multiple types. In- 
corporating this extension is actually quite straightforward. We include this ex- 
tension to show that our framework for visible type application is indeed easy 
to extend - the syntax-directed system we study in this section is essentially a 
merge of System V and the bidirectional system from our previous work |23j . 
This system is also the basis for our implementation in GHC. 

As an example, the following function does not type check in the vanilla 
Hindley-Milner type system, assuming id has type V a. a — > a. 

let foo = \f — )• (f 3, f True) in foo id 

Yet, with the RankNTypes language extension and the following type anno- 
tation, GHC is happy to accept 

let foo :: (V a. a — > a) — > ( Int , Bool) 
foo = Xf — » (f 3, f True) 

in foo id 

Visible type application means that higher-rank arguments can also be ex- 
plicitly instantiated. For example, we can instantiate lambda-bound identifiers: 

let foo :: (V a. a — > a) — > ( Int — >• Int , Bool) 
foo = Xf —> (f @lnt , f True) 

in foo id 

Higher-rank types also mean that visible instantiations can occur after other 
arguments are passed to a function. For example, consider this alternative type 
for the pair function: 


18 Richard A. Eisenberg, Stephanie Weirich, and Hamidhasan G. Ahmed 

pair :: V a. a — )• V b. b — ► (a, b) 

pair = A x y — > (x,y) 

If pa/r has this type, we can instantiate £> after providing the first component for 
the pair, thus: 

bar = pair ’x’ @Bool 

— bar inferred to have type Bool — ► (Char, Bool) 

In the rest of this section, we provide the technical details of these language 
features and discuss their interactions. In contrast to the presentation above, 
we present the syntax-directed higher-rank system first, for two reasons: under- 
standing a bidirectional system requires thinking about syntax, and thus the 
syntax-directed system seems easier to understand; and we view the declarative 
system as an expression of properties - or a set a metatheorems - about the 
higher-rank type system. 

6.1 System SB: Syntax-directed Bidirectional Type Checking 

Figures [8] and [9] show System SB, the higher-rank, bidirectional analogue of 
System V, supporting predicative higher-rank polymorphism and visible type 
application. 

This system shares the same expression language of Systems HMV and V, 
retaining visible type application and type annotations. However, types in Sys- 
tem SB may have non-prenex quantification. The body of a specified polytype 
v is now a phi-type <f>: a type that has no top-level quantification but may have 
quantification to the left or to the right of arrows. Note also that these inner 
quantified types are us, not crs. In other words, non-prenex quantification is over 
only specified variables, never generalized ones. As we will see, inner quantified 
types are introduced only by user annotation, and thus there is no way the sys- 
tem could produce an inner type scheme, even if the syntactic restriction were 
not in place. 

The grammar also defines rho-types p, which also have no top-level quantifi- 
cation, but inner quantification can happen only to the left of arrows. We get 
from specified polytypes (which may quantify to the right of arrows) to rho-types 
by means of the prenex operation, which appears in Fig. [9] 

System SB is defined by five mutually recursive judgments: T hj b e => <f>, 
r l^ b e => v, and T e => a are synthesis judgments, producing the type as 
an output; r hr b e <= p and T l^ b e <= v are checking judgments, requiring the 
type as an input. 

Type synthesis The synthesis judgments are very similar to the judgments 
from System V, ignoring direction arrows. The differences stem from the non- 
prenex quantification allowed in SB. The level of similarity is unsurprising, as 
the previous systems essentially all work only in synthesis mode; they derive 
a type given an expression. The novelty of a bidirectional system is its abil- 
ity to propagate information about specified polytypes toward the leaves of an 
expression. 
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The grammar for SB extends that for System HMV (Fig. [ 3 ]) : 


= . . . expressions p 

= . . . monotypes tjj 

= ■ I r, x:a I r, a contexts v 


= t | vi — > p 2 rho-types 
= r | Vi — > V 2 phi-types 
= Va. 4> specified polytypes 

= V{a}.w type schemes 


r Ijb e => <j> Synthesis of types without top-level quantifiers 


r,x:r ^ e 


r (jb A®. e 


-SB Abs 


r ifb e => Va. <j> 
no other rule matches 


SB Int 


F k be 


cp[T/a\ 


-SB InstS 


F b, n => Int ~ 


r&e: 


Synthesis of specified polytypes 


®:V{a}. v £ r 
u[r/a] 




SB Var 


F ^ ei =4- vi 


■ V2 


r t b e 2 


Vl 


r 4 ei e 2 


v 2 


r\-r 

r lf b e => Va. v 


F \f h e @r => v[t/ a] 
r tf b e " ei => CJ 1 r, x:cn lb e 2 


SB TApp 


r \- v v = Va, b. < 
F, a lf b e <= 4> 


r 4 (Aa.e : v) 


SB App 


-SB Annot 


v 


V2 


F If, let x = ei in e 2 


V2 


SB Let 


r lib e =4- <j> 

no other rule matches 


r If" e =► a 


Synthesis with generalization 

r| b e=^u a = ftv(v)\ftv(r) 
r^ n e=>V{a}.v 


r&e: 


SB Gen 


-SB Phi 


r ^ e <= p 


Checking against types without top-level quantifiers 
F (f b n ei => cri r, x:cn lib e 2 <= p 2 


F lib let x = ei in e 2 -4= p 2 


-SB DLet 


r, x-.vi Ifb e<= p 2 


F Ijb As. e <= v\ 


P2 


-SB DAbs 


r lib e =>■ Vi Ui <dsk p2 
no other rule matches 


r kb e 


P2 


-SB Infer 


rk h e 


Checking against specified polytypes 


prenex(v) = ka.p 
a qL ftv(r) F lib e 
r%,e<=v 


-SB DeepSkol 


Fig. 8. Syntax-directed bidirectional type system 
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o 1 <b <72 


Higher-rank instantiation 


B Refl 

r <b t 


</>i [t/ 6] < b 02 

Va, b. 0i <b Va. 02 


InstS 


V 3 <b Vl V2 <b«4 „ „ 

B Fun 

Vi -> t>2 <b t>3 — ► v± ~ 


^i[t/«] <b i >2 b£ftv(V{a}.v i) 

V{a}.ui < b V{6}. V2 


InstG 


01 <dsk P2 


Subsumption, after deep skolemization 


DSK Refl 

t <li r 


V3 <dsk Vl V2 <dsk P4 „„ T . _ 

DSK Fun 

Vl ->■ V 2 <J sk u 3 — > p 4 


o 1 <dsk V2 


Deep skolemization 


prenex (v 2 ) = Vc.p 2 
0i[r/ffl][r'/fe] <j sk p 2 
V{a}, 6. 0i < dsk u 2 


Inst 


Define prenex(v) = Va. p as follows: 


prenex (Va. r) = Va. r 

prenex (V a. vi —tv 2 ) = Va, b.v i — » p 2 
whereV6.p2 = prenex (v 2 ) 


Examples: 


Va. a — > Vb. b — » b 
Va. a — > Vb. b — » 6 
Va. a — » V6. b — > b 

( Int — » /nt) — » Bool 


<b /nt — > Bool — > Bool Can instantiate non-top-level vars 

<b /nt — » V6. b — > b Not all vars must be instantiated 

<b Va. a — > Bool — > Bool Can skip a top-level quantifier 
<b (Va. a — » a) — » Bool Contravariant instantiation 


Int — >• Va, b. a — > b j£b Int — > Vb. Bool — > b Spec, vars are inst’d from the right 

Int — > Va. a — > a j£b Va. Int — > a —¥ a Cannot move V for spec, vars 

Int — >• Va, b. a — > b <d Sk Int — > Vb. Bool — > b <d sk can inst. spec, vars in any order 

Int — >• Va. a — » a <d Sk Va. Int —t a —¥ a Spec. V can move with <d Sk 

(Int —t Vb. Int Ads k 

(Va, b. a — » b — t b) — > Int Contravariant out-of-order inst. 

V{a}. a — > a <d Sk Va. a — > a Same handling of spec, and gen. vars 


Fig. 9. Higher-rank subsumption relations 


Type checking Rule SB_DAbs is what makes the system higher-rank. The 
checking judgment r 1^ e V= p pushes in a rho-type, with no top-level quan- 
tification. Thus, SB_DAbs can recognize an arrow type V\ — > p 2 . Propagating 
this type into an expression Xx. e, SB_DAbs uses the type Vi as t’s type when 
checking e. This is the only place in system SB where a lambda-term can ab- 
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stract over a variable with a polymorphic type. Note that the synthesis rule 
SB_Abs uses a monotype for the type of x|^] 

Rule SB_Infer mediates between the checking and synthesis judgments. 
When no checking rule applies, we synthesize a type and then check it according 
to the <d s |< deep skolemization relation, taken directly from previous work and 
shown in Fig. [9] For brevity, we don’t explain the details of this relation here, 
instead referring readers to Peyton Jones et al. [l23l Sect. 4.6] for much deeper 
discussion. However, we note that there is a design choice to be made here; 
we could have also used Odersky-Laufer’s slightly less expressive higher-rank 
subsumption relation m instead. We present the system with deep skolemiza- 
tion for backwards compatibility with GHC. See App.[H]for a discussion of this 
alternative. 

The entry point into the type checking judgments is through the r l| b e <= v 
judgment. This judgment has just one rule, SB_DeepSkol. The rule skolem- 
izes all type variables appearing at the top-level and to the right of arrows. 
Skolemizing here is necessary to expose a rho-type to the r ^ e <= p judgment, 
so that rule SB_DAbs can firej^] For example, if the algorithm is checking 
against type Va.a — > \/b. b — > a, it will skolemize both a and 6, pushing in the 
type a —)•&—)• a. As before, by stripping off the V a and V 6, those variables 
behave as type constants. 

The interaction between rule SB_DeepSkol and SB_Infer is subtle. Deep 
skolemization is necessary in SB_DeepSkol because SB_Infer uses the r lj b 
e => v synthesis judgment in its premise, instead of the r f^ b ™ e => er judgment. 
This decision to avoid generalization was forced by GHC, where generalization is 
intricately tied into its treatment of let-bindings and not supported for arbitrary 
expressions. Compare SB_Infer with B_Infer, whose premise synthesizes a 
er-type. This difference means that, in the syntax-directed system, we require 
more instantiations in the typing derivation above the SB_Infer rule. If the 
checked type were not deeply skolemized, certain inner-quantified variables would 
be unavailable for instantiation. For an illuminating example, see Fig. |10| 

6.2 System B: Declarative specification 

Figure [Tl] shows the typing rules of System B, a declarative system that accepts 
the same programs as System SB. This declarative type system itself is a novel 
contribution of this work. (The systems presented in related work PJ] EQ GS 
are more similar to SB than to B.) 

Although System B is bidirectional , we claim that it is also declarative. In 
particular, the use of generalization (B_Gen), subsumption (B_Sub), skolem- 

9 Higher-rank systems can also include an “annotated abstraction” form, \x:v. e. This 
form allows higher-rank types to be synthesized for lambda expressions as well as 
checked. However, this form is straightforward to add but is not part of GHC, which 
uses patterns (beyond the scope of this paper) to bind variables in abstractions. 
Therefore we omit the annotated abstraction form from our formalism. 

10 Our choice to skolemize before SB DLet is arbitrary, as SB DLet does not in- 
teract with the propagated type. 
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Assume F = x:V{a}. Int — > a — > a. We wish to type-check the expression (x:lnt — > 
Va. a — > a). Here is a valid derivation in System B: 


a::V{a}. Int — > a — > a £ F 
F ^ x => V{a}. Int — > a — > c 


B_Var V{a}. Int — k CL — k CL - . . 


B 


Int — > Va. a 


B 


Int — k Va. a 


r ^ (x : Int — k Va. i 


2) =*> Int — »■ Va. a 


B Annot 


InstG 

Infer 


Here is a valid derivation in System SB: 


Int 


a;:V{a}. Int — > a — ► a G F 


Int 


F\i h x 


Int 


SB Var 


Int 


CL — y CL ^dsk 

Int — > a - 


r kb x 


Int 


F £ x <= Int — » Va. a 


DSK_Refl 
DSK_Inst 
SB Infer 


r lj b (x : Int —y Va. a — > a) =>■ Int — > Va. a 


r (x : Int —y Va. 1 


2) => Int — » Va. a 


SB_DeepSkol 

SB_Annot 
- SB Gen 


Note the deep skolemization in this derivation. If we did only a shallow skolemization 
at the point we use SB_DeepSi<OL, then a would not be skolemized. Accordingly, it 
would be impossible to instantiate the type of x with a in the use of the SB Var rule. 


Fig. 10. An example of why deep skolemization in SB DeepSkol is necessary 


ization (B_Skol), and mode switching (B_Infer), can happen arbitrarily in 
a typing derivation. Understanding what expressions are well-typed does not 
require knowing precisely when these operations take place. 

The subsumption rule (B_Sub) in the synthesis judgment corresponds to 
HMV_Sub from HMV. However, the novel subsumption relation <b used by 
this rule, shown at the top of Fig.[9j is different from the <d s k deep skolemization 
relation used in System SB. This o\ <b <72 judgment extends the action of 
<(,mv to higher-rank types: in particular, it allows subsumption for generalized 
type variables (which can be quantified only at the top level) and instantiation 
(only) for specified type variables. We could say that this judgment enables inner 
instantiation because instantiations are not restricted to top level. See also the 
examples at the bottom of Fig. [9] 

In contrast, rule B_Infer (in the checking judgment) uses the stronger of 
the two subsumption relations <d s k- This rule appears at precisely the spot in 
the derivation where a specified type from synthesis mode meets the specified 
type from checking mode. The relation <d S k subsumes <b ; that is, ay <b i '2 
implies ay < ds k '<-' 2 ■ 
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rk e: 


Synthesis rules for System B 


x:a £ F 
r^x=>a 


B Var 


r, x-.T Ig e => v 
F Ig Xx. e =4 t — > v 


B Abs 


F Ig e\ => vi — > v 2 F Ig e 2 4= vi 
r t ei ei => vi 


B App 


r Ig ei =4> o\ r, x:a 1 Ig e- 2 . =4- o 
F hr let x = ei in e? => u 


F b n => Int ~ 


B Let 


B Int 


F ^ e => <j a £ ftv(F) 
F Ig e =4- V{a}. <7 


B Gen 


fh T 

T lg e => Va. v 


r B TApp 


-T Ig e =4 (Ti cri < b (72 
_T Ig e =4 (72 

fht) v = Va, 6. <p 
F, a Ig e <= (p 


B Sub 


-T Ig e @r =4 i>[r/a] F Ig (Aa.e : v) => v 

r Ig e 4= v Checking rules for System B 


B Annot 


r, x:vi Ig e 4= t >2 
r Ig Xx. e 4= V\ — ¥ V 2 

r Ig e 4= v a £ ftv(r) 
F Ig e 4= Va. v 


B DAbs 


B Skol 


F Ig ei =4 (71 
T, s:cri Ig e 2 4= v 
F Ig let x = ei in e 2 4= u 

-T Ig e =4 (71 (71 <dsk U2 

r b e <4= % 


B DLet 


B Infer 


Fig. 11. System B 


Properties of System B and SB We can show that Systems SB and B admit 
the same expressions. 

Lemma 7 (Soundness of System SB). 

1. If r e => <p then r Ig e => (f>. 

2. If T \^ h e => v then r Ig e =4 v. 

3. If r 1^" e => (7 then r Ig e => a. 

4- If r fg b e 4= v then r fg e 4= v. 

5. If r lg b e 4= p then r Ig e 4= p. 

Lemma 8 (Completeness of System SB). 

1. If r Ig e =4 cr then r e =4 a' where a' <b a. 

2. If r Ig e 4= v then r l| b e 4= v. 

What is the role of System B? In our experience, programmers tend to prefer 
the syntax-directed presentation of the system because that version is more 
algorithmic. As a result, it can be easier to understand why a program type 
checks (or doesn’t) by reasoning about System SB. 
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However, the fact that System B is sound and complete with respect to 
System SB provides properties that we can use to reason about SB. The main 
difference between the two is that System B divides subsumption into two dif- 
ferent relations. The weaker <b can used at any time during synthesis, but it 
can only instantiate specified variables. The stronger <d s k is used at only the 
check/synthesis boundary but can generalize and reorder specified variables. 

The connection between the two systems tells us that B_Sub is admissible 
for SB. As a result, when refactoring code, we need not worry about precisely 
where a type is instantiated, as we see here that instantiation need not be fixed 
syntactically. 

Likewise, the proof also shows that System B (and System SB) is flexible with 
respect to the instantiation relation <b in the context. As in System HMV, this 
result implies that making generalized variables into specified variables does not 
disrupt types. 

Lemma 9 (Context Generalization). Suppose T' <b T . 

1. If r 1^ e =>• a then there exists o' <b o such that T' 1^ e =>• o' . 

2. If r 1^ e 4= u and v <b v' then T' lg e 4= v' . 

Proofs of these properties appear in App. 0 


6.3 Integrating visible type application with GHC 


System SB is the direct inspiration for the type-checking algorithm used in our 
version of GHC enhanced with visible type application. It is remarkably straight- 
forward to implement the system described here within GHC; accounting for 


the behavior around imported functions (Sect. 3.1 1 was the hardest part. The 
other interactions (the difference between this paper’s scoped type variables and 
GHC’s, how specified type variables work with type classes, etc.) are generally 
uninteresting; see App. [B] for further comments. 

One pleasing synergy between visible type application and GHC concerns 
GHC’s recent partial type signature feature [S5|. This feature allows wildcards, 
written with an underscore, to appear in types; GHC infers the correct replace- 
ment for the wildcard. These work well in visible type applications, allowing 
the user to write as a visible type argument where GHC can infer the ar- 
gument. For example, if f has type V a b. a — > b — >• (a, b ), then we can write 
f @ @[/nt] True [] to let GHC infer that a should be Bool but to visibly instan- 
tiate b to be [Int], Getting partial type signatures to work in the new context 
of visible type applications required nothing more than hooking up the pieces. 


7 Related work and Conclusions 

Implicit arguments in dependently-typed languages Languages such as 
Coq [B] , Agda ESj , Idris |T) and Twelf m are not based on the HM type system, 
so their designs differ from Systems HMV and B. However, they do support 
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invisible arguments. In these languages, an invisible argument is not necessarily 
a type; it could be any argument that can be inferred by the type checker. 

Coq, Agda, and Idris require all quantification, including that for invisible 
arguments, to be specified by the user. These languages do not support general- 
ization, i.e. , automatically determining that an expression should quantify over 
an invisible argument (in addition to any visible ones). They differ in how they 
specify the visibility of arguments, yet all of them provide the ability to override 
an invisibility specification and provide such arguments visibly. 

Twelf, on the other hand, supports invisible arguments via generalization and 
visible arguments via specification. Although it is easy to convert between the 
two versions, there is no way to visibly provide an invisible argument as we have 
done. Instead, the user must rely on type annotations to control instantiations. 


Specified vs. generalized variables Dreyer and Blume’s work on specifying 
ML’s type system and inference algorithm in the presence of modules [5| intro- 
duces a separation of (what we call) specified and generalized variables. Their 
work focuse on the type parameters to ML functors, finding inconsistencies be- 
tween the ML language specification and implementations. They conclude that 
the ML specification as written is hard to implement and propose a new one. 
Their work includes a type system that allows functors to have invisible argu- 
ments alongside their visible ones. This specification is easier to implement, as 
they demonstrate. 

Their work has similarities to ours in the separation of classes of variables 
and the need to alter the specification to make type inference reasonable. In- 
terestingly, they come from the opposite direction from ours, adding invisible 
arguments in a place where arguments previously were all visible. However, de- 
spite these surface similarities, we have not found a deeper connection between 
our work and theirs. 


Predicative, higher-rank type systems As we have already indicated, Sys- 
tems B and SB are directly inspired by GHC’s design for higher-rank types [25] . 
However, in this work we have redesigned the algorithm to use lazy instantiation 
and have made a distinction between specified polytypes and generalized poly- 
types. Furthermore, we have pushed the design further, providing a declarative 
specification for the type system. 

Our work is also closely related to recent work on using a bidirectional type 
system for higher-rank polymorphism by Dunfield and Krishnaswami m , called 
DK below. The closest relationship is between their declarative system (Fig. 4 
in their paper) and our System SB (Fig. [8]). The most significant difference is 
that the DK system never generalizes. All polymorphic types in their system 
are specified; functions must have a type annotation to be polymorphic. Conse- 
quently, DK uses a different algorithm for type checking than the one proposed 
in this work. Nevertheless, it defers instantiations of specified polymorphism, 
like our algorithm. 
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Our relation <d s k, which requires two specified polytypes, is similar to the 
DK subsumption relation. The DK version is slightly weaker as it does not 
use deep skolemization; but that difference is not important in this context. 
Another minor difference is that System SB uses the r e => <f> judgment 
to syntactically guide instantiation whereas the the DK system uses a separate 
application judgment form. System B - and the metatheory of System SB - also 
includes implicit subsumption <b , which does not have an analogue in the DK 
system. A more extended comparison with the DK system appears in App. |H| 


Conclusion This work extends the HM type system with visible type applica- 
tion, while maintaining important properties of that system that make it useful 
for functional programmers. Our extension is fully backwards compatible with 
previous versions of GHC. It retains the principal types property, leading to 
robustness during refactoring. At the same time, our new systems come with 
simple, compositional specifications. 

While we have incorporated visible type application with all existing fea- 
tures of GHC, we do not plan to stop there. We hope that our mix of specified 
polytypes and type schemes will become a basis for additional type system ex- 
tensions, such as impredicative types, type-level lambdas, and dependent types. 
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A Extended examples using visible types 

In this section we present two longer examples that benefit from the addition of 
visible type application. The second expands and explains the code presented in 
Sect. E] 

A.l Deferring constraints to runtime 

Recent work [2] uses the following definition to enable mixing static and dynamic 
typing in order to implement information-flow control in Haskell p*~| 

class Deferrable (c :: Constraint ) where 
assume :: V a. Proxy c — >• (c => a) — >• a 

The parameter to the class Deferrable is a constraint kind - that is, the kind 
classifying constraints that appear to the left of =>. For example, Show a is a 
Constraint. The idea behind Deferrable is that, if a constraint is deferred, the 
program calculates at runtime whether or not the constraint holds. 

Let’s consider deferring an equality constraint, written ~ r 2 in Haskell. 
Equality constraints are ordinary constraints; in particular, they have kind 
Constraint and can thus be deferred. However, if we have some type variable 
a and wish to check if a is, say, Bool at runtime, we need runtime type informa- 
tion. Haskell’s Typeable feature m implements runtime type information. If we 
have a function, 

woozle :: Typeable a => a — >• a 

then runtime information identifying the type a is available at runtime, in the 
body of woozle. 

Putting this all together, it seems reasonable to defer an equality constraint 
between two types if we have runtime type information for both of them: 

instance ( Typeable a, Typeable b) 

=>■ Deferrable (a ~ b) where ... 

However, to implement assume, we need one more definition. 


Propositional equality: Recent standard libraries shipped with GHC 

contain the following datatype: 

data a :~: b where 

Ref I :: a :~: a 

11 Much of this example - including its use of deferring equality constraints - appears 
in Buiras et al. |2]. However, our use of visible type application in this example is 
our own contribution, novel in this paper. 
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This datatype implements propositional equality. If you have a value pf :: t\ 
r 2 , that is a proof that types T\ and r 2 are equal. Pattern matching on pf reveals 
this equality to GHC’s type-checker, which can then use it in a pattern match: 

boolCast :: ( a Bool ) — > a — > Bool 

boo I Cast pf b = case pf of Ref I — ► b 


Runtime cast The Typeable feature uses in an important function: 

eqT :: ( Typeable a , Typeable b) => Maybe (a :~: b) 

Given runtime type information for a and 6, this function conditionally provides 
a proof that a and b are equal. The eqT function, in turn, can be used to 
implement a runtime cast. 

We are now ready to assemble the pieces: 

instance ( Typeable a, Typeable b) 

=>■ Deferrable (a ~ b) where 
assume _x = case eqT :: Maybe (a :~: b) of 
Just Ref I — >• x 

Nothing -terror" type error!" 


Making assumptions Suppose we are working a list type that tracks whether 
it has surely one element, or whether there is an unknown length^Here are the 
relevant definitions: 

data Flag = Branched — 0 or more elements 
| Unbranched — exactly 1 element 

data List a (b :: Flag) = ... 

the :: List a Unbranched — ► a 
the = ... 

In some places, it is hard to arrange for the type system to ascertain that a list 
is Unbranched , and calling the is impossible. However, with Deferrable , we can 
get around that pesky static type system: 

unsafeThe :: V a b. Typeable b => List a b — >• a 
unsafeThe f 

= assume ( Proxy :: Proxy ( b ~ Unbranched)) 

( the £) 

The call to assume means that the t is type-checked in an environment where the 
constraint b ~ Unbranched is assumed. The call the £ then type-checks without 
a problem. 


12 


This example is from real code - just such a list is used within GHC when keeping 
track of type family axioms from either open mm or closed m type families. 
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Deferring errors with visible type application This last snippet of code 
assumes a constraint, and the only way of specifying the constraint is via a Proxy. 
This is what visible type application can ameliorate. Let’s rewrite this example 
with visible type application. 

class Deferrable ( c :: Constraint) where 
assume :: V a. (c =>■ a) — > a 
instance ( Typeable a , Typeable b) 

=y Deferrable (a ~ b) where 
assume x = case eqT @a @b of 
Just Ref I — > x 

Nothing —>■ error "type error!" 
unsafeThe :: V a b. Typeable b =>■ List a b — » a 
unsafeThe l = assume @(b ~ Unbranched ) (the £) 

We have used visible type applications in two places here. One is to fix the 
type of the call to eqT. Because we immediately pattern-match on this result, 
GHC has no way of inferring the types at which to use eqT. In the previous 
version of this example, it was necessary to write eqT :: Maybe (a b) here. 
This annotation is noisy, because we care only about the a and the b the 
Maybe and bits are fixed and add no information. It is easy to imagine more 
complex cases where the noise far outstrips the signal. 

The second use of visible type application is in the definition and call of 
assume , where no Proxy argument is now necessary. Once again, this has cleaned 
up our code and drastically reduced noise. 

Dependently-typed programming with Proxy Dependently-typed pro- 
gramming in GHC can require more extensive use of proxies. For example, based 
on Conor McBride’s ICFP 2012 keynote m , consider a stack-based compiler for 
a language of boolean expressions. (The entire code for this example is available 
in the supplementary material.) 

data Expr :: *where 
Val :: Bool — > Expr 
Cond :: Expr — ► Expr — > Expr — >■ Expr 
eval :: Expr — ► Bool 
eval ( Val n) = n 

eval ( Cond eO el e2 ) = 

if eval eO then eval el else eval e2 

Using standard techniques, we can create a singleton type for expressions 
SExpr and a type-level function Eval that allow the type system to talk about 
these definitions. 

eval :: Expr — ► Bool 
eval (Val n) = n 
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eval ( Cond eO el e2) = if eval eO then eval el else eval e2 
type family Eval (x :: Expr) :: Bool where 

Eval (’Val n) = n Eval (’ 

Cond eO el e2) = If ( Eval eO) (Eval el) ( Eval e2) 

For example, the evaluator for singleton booleans states that it actually cal- 
culates the boolean denoted by the expression: 

sEval :: SExpr e — > SBool ( Eval e) 
sEval ( SVal n) = n 

sEval ( SCond eO el e2) = slf ( sEval eO) ( sEval el) (sEval e2) 

However, instead of evaluating booleans directly, we would like to compile 
them to a list of instructions for a stack machine. At the same time, we would 
like to know that the resulting list of instruction will produce the correct answer 
when run. 

In other words, given a GADT representing instruction lists, that when run 
will take a stack from its initial configuration to the final configuration: 

data Inst (initial :: [Bool]) (final :: [Bool]) where 
— Add a value to the top of the stack 

PUSH :: Sing v — > Inst s (v s) 

— Compare the top value on the stack and branch 

IFPOP :: Listlnst s st —t Listlnst s sf 
— ► Inst (b ’: s) (If b st sf) 

— a list of instructions, also tracking the machine configurations 
data Listlnst (initial :: [Bool]) (final :: [Bool]) where 

Nil :: Listlnst i i 

(:::) :: Inst i j — > Listlnst j k —t Listlnst i k 

infixr 5 ::: 

— concatenate two lists, composing their stacks 
(++) :: Listlnst i j — > Listlnst j k —¥ Listlnst i k 

Nil ++ ys = ys 

(x : : : xs) ++ ys = x : : : (xs ++ ys) 

infixr 5++ 

We would like to define a compilation function that will create a list of 
instructions that, when run, will put the evaluation of an expression at the top 
of the stack. 

compile :: V (e :: Expr) (s :: [Bool]). 

SExpr e —t Listlnst s ((Eval e) s) 

The implementation of the compilation function is straightforward in the case 
of a singleton boolean value. It just pushes that value on the top of an empty 
stack. 
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compile ( SVal y) = PUSH y ::: Nil 

However, the compilation of conditionals runs into difficulties, we would like 
to use this code, which first compiles the scrutinee, and then appends the branch 
instruction. 

compile ( SCond seO sel se2) = 
compile seO ++ 

IFPOP ( compile sel ) ( compile se2 ) ::: Nil 

However, for this code to type check, the compiler needs to know the following 
conversion fact about if expressions: 

(If (Eva! eO ) ( Eva I el) (Eva! e2)) vs) 

(If (Eval eO) (( Eval el) vs) ((Eval e2) vs)) 

We can “prove” this fact to the compiler, with a helper lemma, called fact 
below. Note, however that in the result of the lemma, the type variables t and 
f only appear as arguments to the type-level function If . Therefore, unification 
cannot be used to instantiate these arguments, so the Proxy type is necessary. 

fact :: V t f s b. Sing b -4 Proxy t -4 Proxy f -4 Proxy s 
-4 ((If btf )': s) (If b (t s) (f s)) 

fact STrue = Refl 

fact SFalse = Refl 

We can call fact in the case for compile , by providing the appropriate Proxy 
arguments. 

compile (SCond seO (sel :: Sing el) (se2 :: Sing e2)) = 
case fact (sEval seO) (Proxy :: Proxy ( Eval el)) 

(Proxy :: Proxy (Eval e2)) (Proxy :: Proxy s) of 
Refl -4 compile seO ++ 

IFPOP (compile sel) (compile se2) ::: Nil 

Note, that in our definition of fact above, we have made the argument s be 
specified via Proxy , even though it doesn’t technically need to to be because it 
appears outside of the If in the type. GHC will also accept this alternative fact ’ 
that does not include a Proxy s argument. 

fact ’ V t f s b. Sing b -4 Proxy t -4 Proxy f 
-4 ((If btf)': s) (If b (t s) (f s)) 

fact ’ STrue = Refl 

fact ’ SFalse = Refl 

However, that version of fact is even more difficult to use. Because the result 
of fact ’ is used as the argument of GADT pattern matching, GHC cannot use 
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unification to resolve type variables in this type. Instead, to make this code type 
check, we require an even more extensive type annotation: 

compile ( SCond ( seO :: Sing eO) 

( sel :: Sing el) ( se2 :: Sing e2)) = 
case ( fact ’( sEval seO) 

( Proxy :: Proxy ( Eva I el)) 

( Proxy :: Proxy (Eva I e2)) :: 

((If (Eval eO) (Eval el) (Eva! e2)) s) 

(If (Eval eO) ((Eval el) s) ((Eval e2) s))) of 

Ref, I — > compile seO ++ 

IFPOP (compile sel) (compile se2) ::: Nil 

In the presence of visible type application, we would like to avoid the proxies 
all together: 

fact :: V t f s b. Sing b — > 

((If btf ) ’: s) :~: (If b (t ’: s) (f ’: s)) 
fact STrue = Refl 
fact SFalse = Refl 

and supply the type arguments visibly: 

compile (SCond seO (sel :: Sing el) (se2 :: Sing e2)) = 
case fact @(Eval el) @(Eval e2) @s (sEval seO) of 
Refl — ► compile seO ++ 

IFPOP (compile sel) (compile se2) ::: Nil 


B Integrating visible type application with GHC 

Below, we describe describe interactions between visible type application and 
other features of GHC and some possible extensions enabled by our implemen- 
tation. 

B.l Case expressions 

Typing rules for case analysis and if-expressions require that all branches have 
the same type. But what sort of type should that be? For example, consider the 
expression 

if condition then id else (Ax — »• x) 

Here, id has a specified polytype of V a. a — > a, but the expression Ax — > x does 
not. To make this code type check, GHC must find a common type for both 
branches. 
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One option would be to generalize the type of Ax — > x and then choose 
V 3. a d a as the common supertype of itself and V{a}. a — > a. However, that 
may not be possible in general, as there may not always be a common instance 
of both types. 

Instead, following prior work [23], we require that if and case expressions 
synthesize monotypes. Accordingly, the type checker instantiates the type id 
above before unification. 

Note that specified polytypes are still available for type checking because 
we know the type that each branch should have. For example, the following 
declaration is accepted: 

checklf :: Bool — > (V a. a — > a) — > (Bool, Int ) 

checklf b = if True 
then A f — > ( f True , f 5) 
else A f — > ( f False, f 3) 


B.2 Type classes 

Consider the Monad type class: 

class Applicative m => Monad m where 
return :: a — >• m a 

(;§=) :: m a — > (a — >■ m b) — > m b 


The return and (>*=) functions have user-supplied type signatures and thus have 
specified type parameters. But in what order? Our implementation uses the 
following simple rule: class variables come before method variables. The full types 
of these methods are thus 

return :: V m. Monad m=^V a. a ^ m a 

(^=) :: V m. Monad m =>V a b. m a — ► (a — > m b) — )• m b 

Note that, in the type of return, m is quantified before a, even though a appears 
first in the user-supplied type. 

B.3 Instantiate types when inferring 

When a variable is defined without an explicit type annotation, are its param- 
eters specified or generalized? According to the systems laid out in this paper, 
the answer depends on the variable’s definition. For example: 


id a — y a 
id x = x 

myld = id 
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According to our technique of lazy instantiation, the use of id in the body of 
myld is not instantiated. The variable myld thus gets the same type - with its 
specified type parameter - of id. 

However, in GHC, we add an extra step: when inferring the type of a variable, 
deeply instantiate the right-hand side before generalizing. In this example, id 
would get deeply instantiated (that is, all top-level type parameters variables 
and all type parameters to the right of arrows) before generalizing, giving myld 
a type V {a}, a — > a, where the type parameter has been generalized. 

This design choice solves all three of the following problems: 

— Haskell includes the monomorphism restriction. This restriction states that 
no variable (as distinct from function, which is defined by pattern-matching 
on arguments) may have a type that includes a class constraint. 

Consider the definition myAbs = abs. The type of abs is V a. Num a => a — )• a. 
According to the monomorphism restriction, myAbs is not allowed to have 
this type - it should get the type Integer — > Integer according to Haskell’s 
defaulting rules. Yet, because of lazy instantiation, the type checker never 
really reasons about the Num constraint and would allow myAbs to have such 
the wrong, polymorphic type. By instantiating deeply and then generalizing, 
the type checker is given a chance to notice the Num constraint and react 
accordingly. 

— Haskellers are used to prenex quantification, where all the Vs are at the top. 
But if we say x = A_ — > id, the naive interpretation of System SB would 
give x::V {a}, a — ► V b. b — ► b. This type is unexpected. Documentation 
for x would include such a strange type, and clients would have to know to 
supply the first term-level argument before visibly instantiating the second. 
By deeply instantiating before generalizing, we give x the type V { a b}. a — »• 
b — > b, which is more in line with expectations. 

— According to our design decision about imported functions in Sect. |3.1[ im- 
ported functions have specified type parameters if and only if the function 
is defined with a user-supplied type signature. However, the algorithm in 
System SB gives myld, above, the type V a. a — ► a, with a specified type 
parameter. This would mean that myld would be available for visible type 
application in its defining module, but any importing modules would see a 
generalized type parameter for myld. This discrepancy does not cause any 
great problems, but it would be unexpected for users. Once again, instanti- 
ating and regeneralizing solves the problem. 


B.4 Overloaded numbers 

Numeric literals in Haskell are overloaded. That is, when we write the number 
3 in code, it can have any type that is a member of the Num class; the type of 3 
is thus Num a => a. It is thus expected that users could write 3 @lnt to get the 
Int 3, instead of an overloaded 3. 

However, this does not work. Here is the partial definition of the Num class: 
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class Num a where 

from Integer :: Integer — ► a 

When a 3 is written in code, it gets translated to fromlnteger 3, where 3 is our 
rendering of the Integer 3. According to our treatment of class methods, the full 
type of fromlnteger is V a. Num a => Integer — > a. This type means that any 
visible type application for an overloaded number literal would have to come 
between the fromlnteger and the number; no straightforward translation from 
Haskell source could accommodate this. If fromlnteger were not a class method, 
we could just define it to have the type Integer ->Va. Num a =>■ a, which would 
work nicely. This option, however, is not available. 

Happily, it is almost as easy to write (3 :: Int) as 3 @/nt, and so we will go to 
no great pains to correct this infelicity. 

B.5 Ramifications in GHCi 

The interactive interpreter GHCi allows users to query the type of expressions. 
Consider what the answer to the following query should be: 

A> let myPair :: V a. a — »• V b. b (a, b) 
my Pair = (, ) 

A > :t myPair 3 

It would be reasonable to respond V b. b — > ( a,b ), recalling that numbers are 
overloaded and we have not yet fixed the type of 3. However, this output loses the 
critical information that the constraint Num a must be satisfied. Alternatively, 
we could generalize before printing, producing V a 6. Num a => b — ► (a, b), but 
that could mislead users into thinking that a is still available for visible type 
application. 

We thus have implemented a middle road, producing V b. Num a => b — > 
(a, b) in this situation. Note that there is no V a, as a is not available for visible 
type application. The Num a constraint is listed after the V b quantification only 
because Haskellers often include type variable quantification before constraints. 
The precise location of Num a is in fact irrelevant, as there is no facility for 
visible dictionary application. 

B.6 Further extensions to visible type application 

Our implementation also gives us the chance to explore two related extensions 
in future work. 


Visible type binding in patterns Consider the GADT 

data G a where 

MkG ::V b. G ( Maybe b) 
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When pattern-matching on a value of type G a to get the constructor MkG, we 
would want a mechanism to bind a type variable to 6, the argument to Maybe. 
A visible type pattern makes this easy: 

case g of 

MkG @b —>■ ... 

The type variable b may now be used as a scoped type variable in the body of 
the match. 


Visible kind application The following function is kind-polymorphic jiJOh 

pr :: V (a :: k i — >- k 2 ) (b :: k 1). Proxy (a b) — > Proxy a 
pr _ = Proxy 

Yet, even with our extension, we cannot instantiate the kind parameters k 1 and 
/c 2 visibly; all kind variables are treated as generalized variables. We expect to 
address this deficiency in future work. 

C Properties of System HMV 

Lemma 10 (Inversion for <hmv )• o'! <h mv 02 if and only if o 3 = 
V{ai}, b 2 , &1.T1 and o 3 = V{a 2 }, 6 2 .T 2 where Ti^ri/~di]\f' 1 /~b 1 ] = r 2 . 

Proof. By unfolding definitions. 

Lemma 11 (Reflexivity for <h mv )• Forall o, o <hmv cr 
Proof. By definition. 


Lemma 12 (Transitivity for <hmv)- If a i <hmv 02 and tr 2 <hmv <03, then 
rr 1 Ahmv 0”3- 

Proof. Let o 3 = V{ 72 r 3 } , 63. T3. Then, by inversion, we know cr 2 = 

V{a 2 }, h,T>2-T2 and r 2 [T 2 /a 2 ][r ' 2 /bj\ = t 3 . We further know o 1 =_ 

V{ai}, 63, b 2 , b 1. n and ri[ri/ai][ri/6i] = r 2 . Thus, Ti[Ti/ai][r / 1 / & i][ fr 2/a 2 ][r 2 /6 2 ] 
t 3 . By the Barendregt convention, we know that ~a 2 do not appear in t\. Thus 
we can rewrite as ri[ri[T 2 /a]/ai][r , 1 [r 2 /o 2 ]/6i][r2/&2] = t 3 . This is enough to 
finish the derivation via HMV InstS and HMV InstG. 


Lemma 13 (Substitution in <hmv)- 

1- Ifv 1 < hmv v 2 , then v 3 [r/a] < hmv v 2 [t/o\. 

2- If (J 1 <hmv &2, then a^r/a] < hmv <r 2 [r/o]. 
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Proof. Immediate. 


Lemma 14 (Context Generalization for HMV). If r l~h mv e : a and 

P ^hmv P y then r lh m v ^ ® • 

Proof. This is by straightforward induction, with an appeal to HMV_Sub in 
the variable case (HMV_Var). 

Proof (Proof of Lemma [^] (Extra knowledge)). This is a corollary of contexts 
generalization as V{a}. r <hmv Va. r. 


D Proofs about System V 

Proof (Proof of Soundness of V against HMV (Theorem By induction on 
the appropriate derivation. Most cases follow directly via induction. 

Case V_InstS This case follows via induction and HMV_Sub using the fact 
that Va. r <hmv rff/a] by HMV_InstS. 

Case V_Var This case follows via HMV_Var and HMV_Sub using the 
fact that V{a}.r < hmv Tpf/a] by HMV_InstG. 

Lemma 15 (Context generalization for V). 

1. If r ^ e : v and r' <hmv r , then there exists v' such that V Ij e : v' and 

P ^hmv V . 

2. If P k} e : t and T' <h mv E , then P' e \ t 

3. If r \^ en e : <7 and P' <hmv r, then there exists o' such that r' l^ e ” e : a' 
and a' <h mv cr. 

In all cases, the size of resulting derivation is no larger than the size of the input 
derivation. 


Proof. By induction on derivations. Most cases are straightforward; we present 
the most illuminating cases below: 


Case V Var: 


1 ::V{a}. v £ T 
r ^ x : wff/a] 


Var 


Given x:\/{a'}. v' £ r' where V{a'}. v' <h mv V{a}. v, we must choose t' such 
that v'\r' /v'} <hmv u[r/a]. Inverting <h mv gives us that v'[r' /a'} <hmv v. 
We are thus done by Lemma [13] Note that the size of both derivations is 1. 

Case V TApp: 

P\~T 

r\t e:Va.v 

v V TApp 

r ^ e @t : v[t/ a] — 
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The induction hypothesis gives us f' ^ e : v' where v' <h 
definition of < 
to Va. v" < 


Va. v. By the 

^hmv > v' must also be quantified over a. We can thus reduce 
^hmv Va. u, which reduces to v" <h mv v. We must prove that 


— hn 

v"[t/o\ <hmv v[t/cl\, which follows directly from v" <hmv 
and so we are done. 

Case V Gen: 


v via Lemma 13 


a = ftv{v) \ ftv(r) r^e:v 

ris en e:V{a}.v ~ 

The induction hypothesis gives us r' ^ e : v' where v' <hmv u- By inversion, 
we know that v' = Va 7 , b . n and v = Va'. T 2 where ti[t' /b] = T 2 - 
Let a — ftv(v) \ ftv(r) and b = ftv(v') \ ftv(r'). We want to 
show that y{b}.v' <hmv V{a}.t;. Expanding out, we want to show that 
V{ 6} , a', b . ri <hmv V{'a}, a'.T 2 , where ri[r/6] = T 2 - Unfolding <hmv shows 
that we want G [r/b] \t' / b ] = T 2 - Choose r = b and we are done. 

Lemma 16 (Type substitution). If T b r then r[r' / a] h r. 

Proof. By the definition of rule Ty_Scoped. Note that substituting in the 
context has no effect. 

Lemma 17 (Substitution for V). Assume a ^ P . That is, a is not a scoped 
type variable. Further, assume f hr. 

1. If r ^ e : t' , then T[r/ a] e : t'[t/ a] . 

2. If r ^ e : v, then T[r/a] hj; e : v[t/o\. 

3. If r \^ en e : a, then T[r/a] \^ en e : cr[r/a]. 

Proof. By induction, frequently using the Barendregt convention to rename 
bound variables to avoid coinciding with free variables. 

Note that a cannot appear anywhere in an expression, as a is not a scoped 
type variable. Thus, any types appearing in expressions are unaffected by the 
substitution [r/a]. This realization covers the V_TApp case. 

The interesting case is generalization: The premise of this case is T hj e : v 
where cr = V{6}.v for b = ftv(v) \ftv(r). By the Barendregt convention, note 
that b do not contain a. 

The induction hypothesis gives us T [r/a] ^ e : v[t / a\. Let c = ftv(v[r/a])\ 
ftv(r[T/a\). To use V_Gen to conclude r tf en e : (V{c}.u)[r/a], we must show 
that b = c and that c are not free in r. 

We now have several cases: 

a is free in both v and in f: In this case ftv(v[r/ a}) includes the free type 
variables of v, minus a, plus the free variables of r. Likewise, ftv(r[r / a]) 
includes ftv(r), minus a, plus the free variables of r. In each case, the sets 
that produce c are changed by the same variables. Therefore, b and c must 
be equal. 
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a is free in v but not free in f: To be in this case a must be in b, which 
cannot happen. 

a is not free in v but is free in f: In this case b = c and we are easily 
done. 

a is free in neither v nor T: In this case the substitution has no effect and 
we are done. 

Proof (Proof of Completeness (Theorem^). We proceed by induction on r lfi mv 

e : a. 

Case HMV_ Var: Straightforward, using the types a to instantiate the vari- 
ables ~a in V_Var. We know these a are not free in r by the Barendregt 
convention. It may be the case that generalization quantifies over more vari- 
ables, i.e. a C a' = ftv(v) \ftv(r ), leading to a more general result type. 
However, that is permitted by the statement of the theorem. 

Case HMV Abs: 


T, X .Ti Ihrnv ^ • T2 

r lh mv Xx. e : Ti -A t -2 


HMV 


Abs 


The induction hypothesis gives us r,x:ri \^ en e : V{a},6.T2 where 72 = 
t^' / b]\f/a\. Inverting ^ en gives us r,x:T\ ^ e : V&.Tj. We can then use 
V_InstS and V_Abs to get r ^ Xx. e : n — > t^t' /b\. Generalizing, we get 
r \f J en Xx. e : V{a, a , }.r 1 -A /b\ where the new variables ~a! come from 
generalizing n and the r' . We can see that (n -A t^t' / b])[r /a] = n — > T2 
and so V{a, a 7 }- t± -a T^ffr' /b\ <hmv ti -A r 2 and we are done. 

Case HMV App: 


^ ^hmv ^1 ■ ^”1 ^ T2 C Ihmv ^2 • TL 

1 1 blmv G ^2 ■ 


HMV App 


The induction hypothesis gives us r tf en ei : V{ai}, b\. r u -A n 2 with 
n = ni[ri/ai][T , 1 /&i] and r 2 = ri 2 [ri/ai] along with T tf en e 2 : 
V{a 2 }, & 2 .r 2 1 with n = r 2 i[r2/a 2 ][r2/& 2 ]. Inverting l^ e " gives us T ^ ei : 
V6i. ru — t T12 and r ^ e 2 : V6 2 - t 2 i. 

We now use the Substitution Lemma (Lemma .0 with the substitution 
[ri/ai] on the first of these to yield C e i : V&i. m [ri/ai] -A Ti 2 [ri/oi]. 
Note t hat the H\ must not be free in T, by inversion of \^ en . Similarly, 
gives us r e 2 : V& 2 - ^21 [r 2 /a 2 ]. 


Lemma 
We can 


17 


then use V_InstS on both of these judgments, to show r 1 -^ ei : 
ni[Ti/aiJ[r , 1 /&i] -A ri2[ri/ai][r , 1 /6i] and r ^ e 2 : T2i[T 2 /a 2 ][T' 2 /& 2 ]. 

We can now now use V_App, as the argument type is equal to ti, established 
earlier. Rule V_App then gives us T ei e 2 : n 2 [tT/oi] T his type, 
as noted earlier, equals r 2 , and so we are done. 

Case HMV Int 

-HMV Int 


r ih, 


hmv 


Int 


Trivial. 
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Case HMV TApp: 


rb T 

U bimv ^ ^ CL. X) 

r fh mv e@r : v[r/a\ 


HMV TApp 


The induction hypothesis (after inverting tf en ) gives us T 1^ e :M a. v' , where 
b = ftv(\/a.v') \ftv(r ) and v'^f/b) <hmv v. Applying V_TApp gives us 
r ^ e@r : v'[t/o\ , and V_Gen gives us T \^ en e@r : V{c}.p'[r/a] where 
c = /tv(u'[r/a]) \ftv(r). We want to show that V {c} . v' [r / a] <hmv u[r/a], 
which follows when there is some t', such that r/fr/ajpr'/c] <hmv t’[r/a]. 
This is equivalent to exchanging the substitution, i.e. finding a r' such that 

w '[ T 7c][r/a] <hmv p[r/a]. 

By Substitution (Lemma 13), we have v'\r/b\ [r/a] <h mv v[t / a\. We also 

-Z=> 


know that the b are a subset of the c. So we can choose t' to be r for the b, 
and the remaining c elsewhere, and we are done. 

Case HMV Let: 


A bimv ■ (7l -U, X.(T\ Ifirnv ^2 ■ (72 

r lh mv let X = ei in e 2 : ct 2 


HMV Let 


The induction hypothesis gives us r \^ en ei : a' x with <h m v Qi- The 


induction hypothesis also gives us T, a;:cri l^ e 
Lemma [15 to get T, x:cr( \^ e 


e 2 : (72 with a 2 <hmv 02 - Use 
e 2 : (72 where cr 2 <hmv cr 2 . 

Let a 2 = V{ 6}. v where b = ftv(v)\ftv(r). Inverting ^ en gives us T, x:a[ ^ 
e 2 : v. We then use V_Let to get F Ij let x = ei in e 2 : v. Generalizing gives 
us r \^ en let x = ei in e 2 : V{ 6} . v. 

Transitivity of <hmv (Lemma [l2| gives us \/{b}.v <hmv <x 2 . 

Case HMV Annot: 


r \-v 

U; CL Ihrr 


V = Va, b. T 
e : t 


rk u 


(Aa.e : v) : v 


-HMV Annot 


The induction hypothesis gives us r \^ en e :\/{b},b .t' with r / [r/6][r / /6 ] = 
r. Inverting \^ en gives us f ^ e : \/b .t'. Applying V_InstS gives us T ^ 
e : r and we can use V_Annot to be done. 

Case HMV_Int: Trivial. 

Case HMV _ Gen: 


Ui hmv e : (7 agftv(r) 
F lhmv e : V{a}. a 


Gen 


The induction hypothesis gives us r \^ en e : a' where a' <h mv (7. We know 
ex' <hmv V{a}. a. In other words, if a' = V{b}. v\ and cr = V{c}. p 2 , we have 
some r such that v\ [r/b] = p 2 . By the definition of <h mv we can use these 
same r to show that a' <hmv V{a, c}. t> 2 . 
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Case HMV Sub: 


r hr.. 


Sub 


The induction hypothesis gives us r \^ en e : a' where a' <h mv By transi- 
tivity of <hmv > we are done. 


E Algorithm V 


In this appendix, we use metavariables Q , R, and S to refer to substitutions 
from type variables a to monotypes r. We apply and compose these as functions, 
homomorphically lifted from type variables to types. 

We suppose the existence of a unification algorithm U, that produces a sub- 
stitution S, with the following properties 


— If S = Ua(Ti,T 2 ) then either S'(ti) = S(t 2 ) and afl dom(S) = 0, or no such 
S exists. 

— If R(ti) = R(t 2 ) (and afl dom(R) = 0) then there exists some S such that 
R = S o Ua{Ti, t 2 ). In other words, unification produces the most general 
unifier. 


We also must define a new operation vars(r) which extracts the scoped type 
variables listed in r. 

With this function, we can define three mutually recursive, partial functions 
that infer the type of an expression in a given context. These equations are to 
be read top-to-bottom. 
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Definition 18 (Algorithm V). 

(1) V(r, Ax. e ) = (Si, Si(b) — > r) when 

V((r,x:b),e) = (S 1 ,r) 

b fresh 

(2) V(r, e x e 2 ) = ( S 3 o S 2 o Si, S 3 (&)) when 

(Si, ti) = V(r, ex) 
(S 2 ,r 2 )=V(S 1 (r),e 2 ) 

S3 = ^ars(r)(S 2 (ri), t 2 — ► 6 ) 
b fresh 

(3) V(r,n) = (e,lnt) 

(4) V(-T, e) = (Si,r) when 

(Si > Va. r ) = V*(r,e) 

a fresh 


(5) V*(r,x) = (e,t>) when 

:r:V{a}. v £ T 
a fresh 

(6) V*(.T, let 2 ; = ei in e 2 ) = (S 2 o Si, n 2 ) wften 

(S 1 ,tr 1 )=V® e "(r,c 1 ) 

(ft,v 2 ) = V*((S 1 (r),*: £ r 1 ),c 2 ) 

(7) V*(r, e @t) = (Si,t>i[r/a]) wften 

(S 1 ,Va.u 1 ) = V*(r,e) 

rh r 

(8) V*(r, (Aa.e : v)) = (S 2 o Si, v) when 

r\-v 

Vo, b.r = v 
(Sx,T')=V((r, a),e) 

S2 = M V ars(r),a,b( T ’ T ') 

(9) V*(r,e) = V(r,e) 


(10) V gen (r,e) = (S,V{a}.t>) when 
(S,v) = V*(-T, e) 
a = ftv(v)\ftv(S{r)) 


Lemma 19 (Soundness of Algorithm V). 
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1 . IfV(r,e) = ( S,t ) then S(r) ^ e : r 

2 . IfV*(r, e ) = (S,v) then S(T) £ e : v 

3 . IfV gen {r , e) = (S» then S(r) If” e : a 

In all cases, dom(S) D vars(r) = 0 . 


Proof. By mutual induction on the structure of e. In the text of the proof, we will 
proceed in order of the clauses in the statement of the lemma, though technically, 
we should be considering the shape of e as the outer-level structure. 

1 . Case e = Xx.e: By ( 1 ), we have V(T, Xx.e) = (Si,Si(b) — ► r), where 

(Si,t) = V((r, x:b), e) and b is fresh. We must show Si(r) ^ Xx.e : 
S-| (b) — >• r. The induction hypothesis tells us Si(r,x:b) h ;c:r. Rewrite 
this as Si(r), x:Si(b) h „ e : t. V_Abs then gives us the desired result. 
Case e = ei e 2 : By ( 2 ), we have V(T, e\ e 2) = (S3 o^o Si, 53(6)), with 
several side conditions from the statement of V. Let R = S3 o S2 o Si. 
We must show i?(T) 1 ^ ei e 2 : 83(b). The induction hypothesis gives us 
Si(r) 1 ^ e\ : Ti and S2 (Si(T)) e2 : r 2 . Furthermore, we know that 
S 3 (S 2 (ti)) = S 3 (r 2 6). 

By the substitution lemma (Lemma 17 1 , we know that R(P) ^ ei : 
S 3 (S 2 (ti)) and R(r) ^ e 2 : S 3 (r 2 ). The first of these can be rewritten 
to R(r) k ei : S 3 (r 2 -»• 6), or R(r) ei : S 3 (r 2 ) -4 S 3 (b). We now 
use V_App to get R(r) ei e 2 : S3 (6) as desired. Note that dom(R) fl 
vars(r) = 0 by virtue of the fact that Si and S 2 meet this condition (by 
the induction hypothesis) and S3 does by the properties of U. 

Case e = n: By ( 3 ), we have V(T, n) = (e, Int). We must prove T n : Int , 
which we get from V_Int. 

Other cases: By ( 4 ), we have V(T, e) = (Si,r), where (Si,Va. r) = 
V*(r,e). By the induction hypothesis, we have Si(T') e : Va. r. By 
V_InstS, we have Si(r) ^ e : t[t/o] for our choice of r. Choose r = a 
and we are done. 

2 . Case e = z: By ( 5 ), we know V*(T, x) = (e,v) where xX/{a}.v £ T. We 

must show r ^ x : v. This is direct from V_Var, choosing r = a. 

Case e = let x = ei in e 2 : By (6), we know V*(T, let x = ei in e 2 ) = (S 2 o 
Si,u 2 ) where (Si,cti) = V sen (T, ei) and (S 2 , f 2 ) = V*((Si(T), a;:<Ji), e 2 ). 
We must show S 2 (Si(.r)) lets = ei in e 2 : t>2- The induction hypothe- 
sis gives us S\(r) \^ en ei : <j\ and S2 (Si(T), x\a\) e 2 : v 2. Substitution 
on the former gives us S2(S\(r)) \^ en e± : S2(<Ji) and we can rewrite 
the latter as S 2 (Si(-r)), a;:S2(cri) ^ e 2 : V2- V_Let gives us our desired 
result. 

Case e = eo @t: By ( 7 ), we know V*(T, eo@r) = (Si, t>i[r/&]) where 
(Si,Va.vi) = V*(r,e). We must show Si(T) ^ eo @r : V\ [r/b\. The 
induction hypothesis gives us Si(T) eo : \/a.v 1, and we are done by 
V_TApp, noting that fhr implies Si(r) b r. 

Case e = (Aa.eo : v ): By (8), we know V*(T, (Aa.eo : v)) = (S 2 o S\,v) 
with side conditions from the statement of V, including Va, b.T = v. 
We must show S2(Si(r)) ^ (Aa.eo ■ v) : v. The induction hypothesis 
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gives us 5i(T, a) e : r' and we also know S 2 (t) = Substitution 

(Lemma [17} gives us S 2 (Si(r, a)) ^ e : 5 2 (t 7 ), which can be rewritten as 
S 2 (Si(r,~a)) ^ e : ^(r). We know by T h v that ftvfr) C vars(r),~d , b. 
However, vars(r), a, b n dom(S 2 ) = 0, so S 2 {t) = t. We thus can use 
V_Annot and we are done. 

Other cases: By (9), we have V*(r, e) = (S,t) where (S,t) = V(T, e). 
We must show S(r) e : t. The induction hypothesis gives us S(r) ly 
e : r. We are done by V_Mono. 

3. All cases: By (10), we know V 9en (r,e) = (S ,\/{a}.v) where (S,v) = 
V*(r, e) and a = ftv(v)\ftv(S(r)). We must show S(r) tf en e:V{a}.n. 
The induction hypothesis gives us S(r) e : v, and we are done by 
V_Gen. 

Lemma 20 (Substitution/generalization). If a = ftv[v) \ ftv(r) and b = 
ftv(S(v))\ftv(S(r)), then ^(Vlal.n) < hm , V{6}. S(v) 

Proof. We must show S'(V{a}.n) <hmv V{&}. S(v). Simplify this to 
V{c}. S(v[c/a]) <hmv V{b}.S(v) where the c are fresh. (They are used to im- 
plement capture-avoidance.) By the definition of <hmv (HMV_InstG), this 
simplifies to 5 , (n[c/a])[r/c] <hmv S(v), for our choice of r. Choose r = 5(a), 
yielding our wanted to be 5(w[c/a])[5(a)/c] <hmv S(v). Simplifying again yields 
5(w[c/a][a/c]) <h mv 5(n), which is the same as S(v) <hmv 5(n). We are done 
by reflexivity of <hmv • 


Lemma 21 (Completeness of Algorithm V). For all contexts T and sub- 
stitutions Q such that dom(Q) l~l vars(r) = 0: 

1. If Q{r) 1 v e : t, then V(T, e) = (5,r 7 ) and there exists R such that Q = 
R o 5 and r = R(t'). 

2. If Q{r) e : v, then V*(T, e) = (5,r/) and there exists R such that 
Q = R o S and v = R(v'). 

3. If Q{r) l^ en e : a , then V gen (r, e) = (5,ct 7 ) and there exists R such that 
Q = R o S and R(a') <hmv o\ 

In the Q = Ro S conclusions above, we ignore any differences on type variables 
that are conjured up as fresh during recursive calls. However, we require that 
dom(R) D vars(r) = 0. 

Proof. We proceed by mutual induction on typing derivations. In each case, we 
must provide the following pieces: 

(i) The result of the call to V (such as (5,r 7 )) 

(ii) The substitution R 

(iii) The fact that dom(R) n vars(r) = 0 

(iv) The fact that Q = Ro S 

(v) The fact that, say, r = R(t') 

These pieces will be labeled in each case. 
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Case V Abs: 


r, x:t i k, e :t 2 
r ly \x. e : ri — > t 2 


V 


Abs 


We know that Q(r),x:r i e : r 2 . Let T' = r,x:b (where b is fresh) and 
<5' = [ Ti/b ] o Q. Then, we can see that Q'{r') ly e : t 2 . We thus use the 
induction hypothesis to get V((-T, x:b ), e) = (S, t 2 ) along with R' such that 
Q' = R' o S and t 2 = R'ir^)- We can thus see that 

(i) V(r, Xx.e) = (S,S(6) -4 t^). 

We have left only to provide i? such that Q = R o S and n — > t 2 = 
R{S(b) -4 r') = R(S(6)) -4 flfa). 

(ii) Choose R = R 1 . 

(iii) The domain restriction follows by the induction hypothesis. 

By functional extensionality, Q — R' o S iff Q applied to any argument is 
the same as R' o S applied to any argument. But in our supposition that 
b is fresh, b is outside the domain of possible arguments to Q\ thus we can 
conclude 

(iv) Q = Q' = R' o S, ignoring the fresh b. 

(v) We can also see that Ti = Q' (b) by definition of Q' and that t 2 = R^) 
by the use of the induction hypothesis. 

Case V App: 


r ^ e\ : n -> t 2 r^e 2 \T 1 

— V_App 

r k ei e 2 : t 2 

The induction hypothesis tells us that V(T, ei) = (Si, r{) with R\ such that 
Q = R\ o Si and n — > t 2 = Ri(t[). Recall that we are assuming Q(r) 
ei e 2 : t 2 , which can now be written as Ri(Si(r)) ei e 2 : t 2 . We thus know 
(by inversion) Ri(Si(r)) e 2 : T\. We then use the induction hypothesis 
on this fact, but choosing Q be Ri, not the Q originally used. This use of 
the induction hypothesis gives us V(Si( Q), e 2 ) = (S 2 , t 2 ) with R- 2 such that 
Ri = R 2 o S 2 and n = R 2 (t'^). We now must find a substitution S3 that is 
a unifier of S 2 (t[) and t'^ — > b for some fresh b. We know Ri(t[) = Ti — > t 2 
and R 2 (t 2 ) = Ti. We can rewrite the former as R2(S 2 (t[)) = n — > t 2 . 
Choose S3 = [r 2 /b\ o R 2 . We see that S^(S 2 (t[)) = S^r^ — > b) as required. 
We also must show that dom(S^) D vars(r) = 0. This comes from the fact 
that b is fresh and that R 2 satisfies the domain restriction by the induction 
hypothesis. We now know that U vars ^r) (S 2 (ti), t 2 — > b) will succeed with the 
most general unifier S3. We thus know that 

(i) V(r, ei e 2 ) = (S 3 oS 2 oSi,S 3 (b)). 

We must now find R. By the fact that S3 is a most general unifier, we know 
that S3 = R o S 3 . 

(ii) Choose R to be this substitution, found by the most-general-unifier 
property. 

(iii) R must satisfy the domain restriction from the fact that both S3 and 
S^ do. 
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(iv) Putting all the facts about substitutions together, we see that R o S 3 o 
S -2 o A-, = Q as needed (ignoring the action on the fresh b) . 

We must finally show r 2 = R(S 3 (b)) = S 3 (b). 

(v) This comes from the definition of S 3 . 

We are done. 

Case V Int: 


rk n: Int 


V 


Int 


(i) V(r,n) = (e, Int). 

(ii) Choose R = Q. 

(iii) By the assumed domain restriction on Q. 

(iv) Q = Roe, quite easily. 

(v) Q(lnt) sure does equal Int. 

Case V_InstS: 

r £ e : Vo. T 

no other rule matches 
r e : t [t / a] 


InstS 


The induction hypothesis gives us V*(T, e) = (S,Va. t') with R' such that 
Q = R' o S and R'(\/H.t') = Va. r. Note that we have liberally renamed 
bound variables here to ensure that the quantified variables ~a are the same 
in both cases. This is surely possible because the substitution R' cannot 
change the number of quantified variables (noting that t' must not have 
any quantified variables itself). We thus know R'{t') = r and that a (~l 
dom(R') = 0. 

(i) We can see that V(T, e) = (S, r'). 

(ii) Choose R to be the [r/a] o R' . 

(iii) The domain restriction is satisfied by the induction hypothesis and by 
the Barendregt convention applied to bound variables a. 

(iv) We can see that Q = R o S as required (ignoring the action on the 
fresh a). 

We have already established that R'(t') = r. We must show that R(t') = 
rpf/a]. 

(v) This follows from our definition of R. 

We are done. 

Case V Var: 


x:V{a}. v € r 
r ^ x : v\t/h\ 


Var 


We know x-M{a}.v € Q(T). Thus, there exists v 1 such that a;:V{a}.t; / € r 
where Q(v') = v. 

(i) Thus, V*(r,x) = (e, v'). 

(ii) Choose R = [r/a] o Q. 

(iii) The domain restriction is satisfied by the assumption of domain restric- 
tion on Q and the Barendregt convention applied to the bound a. 

(iv) Clearly, Q = Roe, ignoring the action on the fresh o. 

We must now show that R(v') = t>[r/a]. 

(v) This is true by construction of R. 



Visible Type Application (Extended version) 


49 


Case V Let: 




n ei : ai T, x:ai e 2 : v 2 
r ^ let x = ei in e 2 : v 2 


V Let 


The induction hypothesis gives us V gen (r,e i) = (Si,<x() with R\ such 
that Q = Ri o S\ and i? 1 (cr^) <h m v 04 . We know (from inversion) 
that Ri(Si(r)),x:ai e 2 : v 2 . We also see that Ri(Si(r), x:a[) <h mv 
Ri(Si(r)),x:cri and thus that i?i(Si(.T), x:a[) Ij e 2 : v 2 , by context gen- 
eralization (Lemma 15 1, which preserves heights of derivations. We thus use 
the induction hypothesis again to get V*((Si(r), x:a[), e 2 ) = ( S 2 ,v ' 2 ) with 
R 2 such that R\ = R 2 o S 2 and v 2 = R 2 (v' 2 ). 

(i) We thus have V*(r, let x = ei in e 2 ) = (S 2 ° Si,v 2 ). 

(ii) Choose R= R 2 . 

(iii) The domain restriction is satisfied via the induction hypothesis. 

(iv) We can see that Q = R 2 o S 2 o Si as desired. 

(v) We can further see that R 2 (v 2 ) = v 2 as desired. 

Case V TApp: 


n- r 

e : Va.u 

r ^ e @t : v[t / a] 


V TApp 


The induction hypothesis gives us V*(r,e) = (S,v') with R' such that 
Q = R' o S and Va. v = R'(v'). Because the substitution R' maps type 
variables only to monotypes, we know v' must be \/a.v", with R'{ v") = v 
and a qL dom(R l ). 

(i) We thus know V*(T, e@r) = (S ,v"\t / a]). 

(ii) Choose R = R' . 

(iii) The domain restriction is satisfied via the induction hypothesis. 

(iv) We already know Q = R' o S. 

We must show R' {v"[t / a]) = v[t / a\. This can be reduced to 

R' {v")[R' (r) / a] = v[t / a] by the fact that a qL dom(R). Furthermore, we 
know r is closed, so we can further reduce to R' {v")[t / a] = v[t/o\. 

(v) But we know R'(v") = v, so we are done. 

Case V Annot: 


r \~ v v = Va, b. t 

r,ak e:r 

r ^ (A a.e : v) : v ~ 


Annot 


The induction hypothesis gives us V((T, a), e) = (Si , t') with R\ such that 
Q = R\ o Si, Ri{t') = r, and dom(Ri) fl vars(r,a) = 0. We must show 
that r and t' have a unifier. We can assume further (by the Barendregt 
convention) that bndom(Ri) = 0. We also know that ftv(r) C vars(r),~a, b. 
Thus, R\ (r) = r and Ri is a unifier of r and t' . Let S 2 = U vars ^ r \ a b( T > T ') 
(which is now sure to exist). 

(i) We thus have V*(T, (Aa.e : v)) = (S 2 o S\,v). 
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(ii) Choose R as determined by the fact that R\ = R o S 2 (gained from the 
most-general-unifier property) . 

(iii) The domain restriction comes from the fact that S 2 and Ri both satisfy 
even a stricter domain restriction than we need here. 

(iv) We thus see that Q = R o S 2 o Si as desired. 

(v) Furthermore, by the fact that v is closed, we get R(v) = v, as desired. 

Case V_Mono: 

r ^ e : T 

no other rule matches 

— V_Mono 

r\^ e:r 

The induction hypothesis gives us V(T, e) = with R such that Q = 

Ro S and R(t') = r. 

(i) We see that V*(T, e) = (. S,t ')• 

(ii) Choose R to be the one we got from the induction hypothesis. 

(iii) The domain restriction is via the induction hypothesis. 

(iv) We see that Q = Ro S. 

(v) We see that R(t') = r. 

Case V Gen: 


a = ftv(v) \ ftv(r) r^e:v 

Tff™e:V{a}.u - 


The induction hypothesis gives us V*(T, e) = {S,v f ) with R such that Q = 
R o S and R(v') = v. We know a = ftv(R(v')) \ ftv(R(S(r))), and let 
a' = ftv(v')\ftv(S(r)). 

(i) We see that V» en (r, e) = (5,V{o / }.i/). 

(ii) Choose R as from the induction hypothesis. 

(iii) The domain restriction is via the induction hypothesis. 

(iv) We know Q = Ro S. 

We must show i?(V{a , }.u / ) <hmv V{a}.u 

(v) This is direct from Lemma |20} 


Proof (Proof of principal types for HMV (Theorem W)- By completeness of V 
(Theorem 5j, we have cr' 0 such that T \^ en e 
of Algorithm V (Lemma 21), we have V ge 
e = Ro S and R(a' p ) <h 

V (Lemma [19} , we know that S(r ) \^ en e : a p , or equivalently: S(r) If 1 
S(a p ). By suostitution, we can substitute through by R to get r 
soundness of V (Theorem |4| , we have T fp, mv e : a 
we assumed nothing about op. Thus, cr p is a principal type for e. 


and ctq <h mv cr. By completeness 
“(T, e) = (S, CTp) with R such that 
CTn. Let cr n = R(a p ). By the soundness of Algorithm 
en e : a(, or equivalently: S(r) \f, en e : 

By 

p . Recall that a p <hmv o’o- But 


qen 


P‘ 


Proof (Proof of decidability of System V (Theorem m All that remains is to 
show that Algorithm V terminates. All cases in Algorithm V except for cases (4), 
(9), and (10) recur on a structural component of the input. We can observe that 
(4) and (9) cannot infinitely recur, because one of the other cases is guaranteed 
to intervene. Because (10) recurs from V 9en (r, e) to V*(T, e), it, too cannot loop. 
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F Higher-rank systems: properties of <b 

This section concerns the properties of the first order subsumption, higher-order 
instantiation relation, tri <b cr 2 . For reference this relation is repeated in Fig. [T2| 


Cl <b Co 


Higher-rank instantiation 


B Refl 

r <b t 


v 3 <b Vl V2 <b«4 „ „ 

B Fun 

Vl —> V2 <b v 3 — > Vi 


</>i[r/6] <b (j>2 
Va, b. 4>i <b Va. ej > 2 


InstS 


wi[t/ a] < b V 2 b 0 ftv(y{a}.vi) 
V{a}. vi <b V{6}. V 2 


InstG 


Fig. 12. Inner instantiation 


Lemma 22 (Monotypes are already instantiated). If <b T 2 then T\ = 
T2- 

Proof. By inversion. 

Lemma 23 (Substitution for instantiation). If ay <b cr -2 then S(a i) <b 
S(a 2 ). 

Lemma 24 (Reflexivity for <b ). For all a, a <b cr. 

Lemma 25 (Transitivity for <b ). If <Ji <b cmd oy <b c 3 , then oy <b 0 - 3 - 
Proof. Proof is by induction on H (a 2 ), where the H function is defined as follows: 
H(r) = 1 

H(v 1 — > v 2 ) = 1 + max(Hvi, Hv 2 ) 

when at least one of v\ and v 2 
is not a monotype 
H(\/a. (j>) = 1 + H(<t>) 

H(V{a}. v) = 1 + H(v) 

Note that the H function is stable under substitution (replacing variables by 
monotypes) . 
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Case oy is r, a monotype In this case, by Lemma [32j we know that <73 must 
also be r. So the result holds by assumption. 

Case <72 is V21 — > V22 By inversion, we know that ay is V{a}, b, c. V\\ — > v \ 2 
such that V21 <b tdi [r/a, c] and U 12 [r/a,c] <b t>i 2 - 

We also know that a 3 is V{d}.t>3i — > U32, such that V31 <b v 2 i an d V22 <b 

^32- 

By induction, we can show U31 <b tu[f/tt,c] and u^T/a, c] <b U32. 

This lets us conclude that ay <b (72- 

Case o' 2 is Va. 02 By inversion, we know that oy is V{&},"a, c. 0i such that 
[r/b,c] < b 02- 

We also know that 03 is V{d}, a±. 0 3 where a = ai, 02 and 02[r'/a2] <b 03- 
By substitution, we can show that 0i[r/&, c][t'/o 2] <b 02 [t , /o 2]- 
By induction, we then have 0i[r/6 , c][tVo 2] <b 03- We can then derive 
oy <b <73 to conclude. 

Case o' 2 is V{a}.iy By inversion, we know that ay is \/{&}.iy where 
vi [r/b] < b v 2 . 

We also know that 0-3 is V{c}. V3, where <b ^3- 

By substitution, we can show that ty ^f/b\^r'/~a\ <b V2 [r'/a]. Rewrite this as 

vi[t[¥ / a]/b\ < b v 2 [T'/a\. 

By induction, we have ty [r[r'/a]/6] <b t'3. 

Therefore we can conclude V{ 6} . ty <b V3. 


G Higher-rank systems: properties of DSK System B 

This section considers the Higher-Rank type systems with deep-skolemization, 
described in Section [G] 


G.l Properties of Prenex conversion 

Lemma 26 (Instantiation and Prenex). If v <b v ' and prenex(v ) = Va. p 
and prenex(v') = V6. p' , then Va. p <b V6. p' and b C A. 


Proof. Proof is by induction on v <b v' . 


Case B InstS: 


01 [7-/ 6] < b 02 

Va, b. 0i <b Va. 0 2 


InstS 


Say that prene x(v) = Va, b,P.p[ where prenex{(f > ) =Vc.p[. 

This means that prenex / b]) = Vc. p'ifr/b\ as r do not contain quanti- 
fiers. 

Say also that prenex(v') = Va, d. 0 ' 2 where prenex{ 4 > 2 ) = Vd. p' 2 . 

By induction, we have that p\ [r/6] <b P 2 where d C c. 

Therefore we can conclude by B_InstS that 
Va. Pi <b V6. p 2 
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Case B Fun: 


V 3 <b Vi v 2 <b Vi 

1 ) 

Vi — k V2 <b V 3 — > Vi 


Fun 


Note that prene x(v\ — k v 2 ) = Va. Vi — k p 2 where Va. p 2 = prenex(v 2 ) and 
the a are not free in v 3 . prenex(v 3 — k Vi ) = \/b.v 3 — k pi where \/b.pi = 
prenex(vi). So by induction, we have that Va. p 2 <b V 6 . pi and b QH. 

By inversion, we have that p 2 [T/a] <b Pi ■ From this we can derive Vi — > 
p 2 \f /n\ <b v 3 —> pi and then Va. V\ p 2 <b V 6 . v 3 — > pi. 

Case B Refl: trivial. 


Lemma 27 (Prenex instantiates). If prene x(v) = Wa.p then v <b p- 


Proof. Proof is by induction on v. If v is a monotype, we are done. If v = Vi — > 
t> 2 , then prenex{v) = Va. p 2 where prenex(v 2 ) = Va. p 2 . By induction, 

we know that v 2 <b p, so by B_Fun, we have Vi — > v 2 <b v\ — > p. 

If v is a specified polytype, of the form Va.</), then prenex(v 2 ) = Va, b. p' 2 
where prenex(cf > ) = \/b.p' 2 . By induction, we know that p\ <b p' 2 . We can then 
show that Va, b. p' x <b p 2 by B_InstS (and instantiating variables with them- 
selves.) 


G.2 Properties of DSK subsumption 

Lemma 28 (Substitution for higher-rank subsumption). If vi <dsk v 2 
then S(vi) <dsk S(v 2 ). If ai <d s k v 2 then S(a 1 ) <dsk S(v 2 ). 

See Vytiniotis et al. [26j Lemma 2.7. 

Lemma 29 (Reflexivity for <d s k )• For all v, v <d s k v. 

Proof. Vytiniotis et al., [22] Lemma 2.21. 

Lemma 30 (Transitivity for <d 5 k )• If v 1 <dsk v 2 and v 2 <d s k v 3 , then 
Vl <dsk v 3 . 

Proof. Vytiniotis et al., [22] Lemma 2.22. 

Lemma 31 (Single skol admissible). If a\ <d s k v 2 then ui <d s k Vc.u 2 (when 
c are not free in a±). 

Proof. Proof is by induction on <d S k v 2 . 

Case DSK_Refl: Direct by DSK_InstS. 

Case DSK Fun: 


v 3 <dsk vi v 2 <dsk Pa 
V\ -> v 2 <* dsk V 3 Pi 


Fun 


Say prenex(v 4 ) = \/b.p. By inversion, we know that vi v 2 <dsk v 3 — > p. 
We also know that prenexifJ c. v 3 — t Vi) = Vc, b. v 3 p, so we can conclude 
with DSK Inst. 
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Case DSK Inst: 


prenex(v2) = Vc. P2 
Mr/aW/b\ <g sk p 2 pgK 
V{a}, b. 4 >i <dsk v 2 


Inst 


We note that prenex(\/c. V2) = Vc, b. p 2 , so we can just apply DSK_Inst. 

Case SB_Inst: 

prenex(v 2) = Vc. P2 

<fi\f If\\t' lb] <5 k P2 

_ J _ ' J ~ dsk ' DSK_Inst 
V{ a}, b. 4 >i <dsk v 2 

Similar reasoning to DSK_Inst. 

Lemma 32 (Monotypes are instantiations). If a <d s k r then <7 <b t. 


Proof. Proof is by induction on a <d 5 k t. In each case the result holds directly 
by induction. 


Lemma 33 (DSK and prenex). For all v, we have v <d s k prene x{v). 


Proof. Proof is by induction on v. 

Lemma 34 (DSK Subsumption contains OL Subsumption). Ifv 1 < 0 i V 2 

then v\ <dsk V2 ■ 


Proof. Proof is by induction on the derivation. 

Case OL_B_ARefl: Trivial. 

Case OL_B_AFun: By induction. 

Case OL_B_ AInstS: 

6i\t l~a\ < 0 | 62 b 4 ftvN~a. d>i) 

1 ' J _ ——OL_B_ AInstS 

Vo. </>i < 0 i V 6 . (f> 2 

By induction we know that (f>i\r/b\ <dsk </>2- We want to show that 
Vo. 4 >i <dsk V 6 . f>2- Say prenex((j)2) = Vc. p2, then by DSK_Inst it suffices 
to show that <p\ \j' /b\ <d s k P2- Note that as Vc. P2 <dsk P2 j by transitivity, 
we can reduce this to showing f>i[T/b] <dsk prenex(cf> 2). 

We can finish, again by transitivity, by showing via Lemma [ 33 l that 2 <dsk 
prenex { 4 > 2). 

Corollary 35 (DSK Subsumption contains Instantiation). If v\ <b V2 

then Vi <dsk V2 ■ 

Proof. See above and Lemma [ 47 ) 

Lemma 36 (Transitivity of Higher-Rank subsumption I). If ay <b 02 

and (J2 <dsk v 3 , then ay <d s k v 3 . 

Proof. Follows from Lemmas [ 30 ] and [ 35 | 

Lemma 37 (Transitivity of Higher-Rank subsumption II). If a 1 <d S k V2 
and V2 <b ^3, then ay <d s k ^3- 

Proof. Follows from Lemmas [ 30 ] and [ 35 ] 
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G.3 Substitution 

Although a more general substitution property is true for these systems, in this 
development we need only substitute for generalized type variables. Therefore, 
we state these lemmas is more restrictive forms. 

Lemma 38 (Substitution for System B). Assume that the domain of S is 
disjoint from the variables of T and from the free type variables of e. 

1. If r e => a then r ^ e => S(a) 

2. If r e <= v then r ^ e <= S(y) 

Lemma 39 (Substitution for System SB). Assume that the domain of S is 
disjoint from the variables of T and from the free type variables of e. 

1. If r ly b e ^ then r e => S(4>). 

2. If r \^ b e => v then r \^ b e => S (v ) . 

3. If r \^ b n e => a then r \^ b n e => S (cr) . 

I If r\% b e<=v then r 4 e 4= S(v). 

5. If r Yg b e <= p then r \^ b e <= S(p). 

G.4 Soundness of syntax-directed system 

Because of the differences between the syntax-directed and the declarative sys- 
tem, we need the following lemma about System B to prove the soundness of 
System SB. 

Lemma 40 (Prenex System B). If T ^ e <= p and prenex(4>) = Va. p then 
r ^ e 4= (f. 

Proof. Case B_DAbs 


r, x:vi ^ e <=v 2 
r 1^ Xx. e <= t>i — > v 2 


DAbs 


In this case, because we are pushing in p, we have v 2 = p 2 - We also know 
that prenex (ip) = Va. V\ — > p 2 , so <f> must be of the form v\ — > v 2 . 

Write v 2 as V~d\.(j) 2 . We also know that prenex(v 2 ) = Vai,a 2 .p 2 where 
prenex(cj) 2 ) = Va 2 . p 2 . 

By induction, we have r,x:v i e <= (f> 2 By (repeated) use of B_Skol, we 
have r, x:vi ^ e * 1 = Va. (j> 2 By B_DAbs, we can then conclude r Xx. e * 1 = 
Vi — > Va. (p 2 , which is what we wanted to show. 

Case B DLet 


r ft ei => cr 1 

r, x:ai ^ e 2 4= v 
r ^ let x = ei in e 2 4= v 


DLet 


This case holds by induction. 
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Case B_Skol This case is impossible, as the conclusion does not have the 
form <j> . 

Case B_ Infer 

r ^ e => or or <dsk V 2 ^ T 

— - — B Infer 

r fb e <*= v 2 

Here we know that v 2 is p. By inversion of a <dsk p, we have a = 
V{ai}, b\. <j > 2 where where prenex(cj) 2 ) = Vc. p and p 2 ^f /~ai]^f' /b\] <dsk P- 
However, as we also have prenex{(ff) = Vat p, we can use the same informa- 
tion to conclude, a <dsk <^, and then use B_Infer to show that T e <= <f>. 

Proof Soundness of System SB Lemma [7] states: 

1. If r [jt, e => <j> then r 1^ e => (f>. 

2. If r e => v then r ^ e => v. 

3. If r \^ n e => a then r 1^ e => cr. 

4. If r f^ b e <= v then r e <= v. 

5. If r Y^ b e <= p then f ^ e p. 

Proof. Most of the cases of this lemma follow via straightforward induction. 
Cases SB_Spec, and SB_Var are similar to the cases for V_InstS and 
V_Var, so are not shown. We include selected cases below. 

Case SB Annot: 


r hr v = Va, b. <f 
r, a If b e<!=(j) 

r ( Aa. e : v) => v 


Annot 


By induction we know that r, a 1^ e <= (f>. By B_ Annot, we can conclude 
r (Aa.e : v) => v. 

Case SB Infer: 


r If b e =>• VI V\ <dsk P2 

no other rule matches 

— SB_Infer 

r tlh e <= p 2 

By induction, we know that T e => V\. We would like to show that 
r e <= p 2 . This follows immediately by B_Infer. 

Case SB DeepSkol 






lb 


: V 


By induction, we have r Y^ e <= p. Note that if prene x(v) = Va. p and v is of 
the form Va'. (f>, then, by definition prenex((f > ) = V~a" . p and a = a 7 , H" . By 
the prenex lemma 40 we know that r Y^ e <= (p. We can then use multiple 


applications of rule B 


Skol to conclude r Y^ e 


■ Va' . (j>. 
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G.5 Completeness of syntax-directed system 
Lemma 41 (Context Generalization). Suppose T' <b r 

1. If r e => <fi then there exists <f>' <b <f> such that r' lj b e => <f>' . 

2. If r \^ b e => v then there exists v' < b v such that r' \^ b e => v' . 

3. If r \^ b n e => a then there exists o' <b er such that F' l^' 1 e => o' . 

4. If r \^ b e ■$= v and v <b v' then T lj b e -f= v' . 

5. If r e <= p and p <b p' then r' h, b e 4= p. 


Proof. Proof is by induction on derivations. 

Case SB_Abs: 

r, x:t Pl, e => v 


-SB Abs 


r h; b Xx. e => r — >■ v 

By induction, we know that F' ,x:t lj b e => v' for v' < b v. Therefore, 
r' Ijb Xx. e => r — > v' and, by SB_Fun, r-M/<br-M). 

Case SB_Int: 

-SB INT 


Trivial. 

Case SB InstS: 


r \ j b n =>■ Int 


e => Va. <f> 
no other rule matches 


J’fb 


rh 


sb ^ 


0[r/‘ 


-SB InstS 


a 


By induction, we know that r \^ b e => v 1 where v' < b Va. <j). By inversion, 
we know that v' must be of the form Va,b.<j>' where (f>'\f'/b\ <b 4> ■ By 
SB_InstS, we can conclude T l| b e => /b])\f/a]. We also need to 

show that (<// [t' / 6])[r /a] <b </>[r/a], which follows by substitution (Lemma 


231. 


Case SB Var: 


c:V{a}. v £ T 
v[r/a 




SB Var 


We know that x:o £ T, where o < b V{a}.t>. So by inversion, a must 


be \/{b}.v' such that v'\f' /b\ <b v. Therefore, by substitution lemma 23 
v'[t' /6][r/a] <b u[r/a]. As we know that the a are not free in v', we can 
rewrite the left hand side as: i/[t'[t/ a}/ h\, and choose those types in the use 
of SB _ Var. 

Case SB App: 


rtt ^ vi App 

r l^b ei e 2 => v 2 

By induction we have r' ly b e i =>• <t> such that </> <b v\ — > V 2 ■ By inversion, 
this means that </> must be of the form v[ — > v 2 where V\ < b v[ and v 2 <b i> 2 - 
By induction, we have r' l^ b e 2 4= v[. So we can conclude by SB_App. 
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Case SB Let: 


r Ifb" ei => a 1 r, x:ai 4 e 2 => v 2 gE 

r lf b let x = ei in e 2 => v 2 


Let 


By induction r' \f b n e\ => er( for a\ <b ay. By induction (again), r',x:a[ lj b 
e-2. => v 2 for v' 2 <b V2- So we can conclude by SB_Let. 

Case SB TApp: 


fh T 

rff b e=>Va.p 

r \^ b e @t => v[t / a] 


TApp 


By induction r' f^ b e => v' where v' <b Va. v. By inversion, v' is of the form 
\/a.v i where V\ <b v. By substitution, V\[t / a\ <b v\r/a\. 

Case SB Annot: 


rhti v = Va, b. (j) 

r, a 4 e 

.T i^ b ( Aa. e : v) => v 


Annot 


By induction, we have T', a f^ b e <= <f>, so we can use SB_Annot to conclude 
r' : b < ->r. 

Case SB Phi: 


r kb e => 4> 
no other rule matches 


J’fb 


-SB 


Phi 


Holds directly by induction. 

Case SB Gen: 


r 4 e =>• v a = ft v ( v ) \ ft v ( r ) cp 
r ff b " e => V-ja}. V 


Gen 


By induction, we have r' lj b e => v' for v' < b v. Let b = ftv(v') \ftv(r). We 
want to prove that V{ 6 }.i/ <b V{a}.u. This holds by B_InstG, choosing 
t = ~a. 

Case SB DAbs: 


r, x:vi 4 e <= P2 
r hj b Xx. e <= — > p-2 


SB 


DAbs 


Let r' <b r and ty — > P2 <b v 1 be arbitrary. By inversion, we know that v' 
is v[ — ► v 2 where v[ < b ty and p 2 <b v 2 . 

By inversion, we know that v 2 must be of the form p' 2 , as <b cannot intro- 
duce specified quantifiers. 

By induction, we know that F' , x:v[ lj b e p 2 . 

So we can conclude by SB_DAbs. 



Visible Type Application (Extended version) 


59 


Case SB Infer: 


r\^ b e^Vi v 1 < dsk p 2 

no other rule matches 
— SB_Infer 

r e <= p 2 


Let r' <b r and p 2 <b p' be arbitrary. By induction, we know that r' lj: b e => 
v' for v' <b vi. We want to show that v' < dsk p' ■ This holds by lemmas 36 
and m 

Case SB DLet: 


r Ifb" e i r > X:(T 1 tb e 2 <1= p2 

i • oJt5 

r ^ b let x = ei in e 2 4= p 2 


DLet 


Let r' <b r and p 2 <b p' be arbitrary. By induction, we have r' \^ b n e\ => a[ 
for er( < b o\. By induction (again), r'^x:a[ lf b e 2 <= p' ■ So we can conclude 
by SB_DLet. 

Case SB DeepSkol 


prenex{v ) =Va.p 

a qL ftv\r ) r ^ 

r&e^v 


— SB DeepSkol 


Let r' <b r and v < 


Sb v 


Lemma 27 


be arbitrary. Let prenex(v') = Va'.p 1 . By 


we know that p <b p' ■ 

So by induction, T' ly b e p' 

Therefore, we can use SB_DeepSkol to conclude. 


Proof of Completeness of System SB Lemma [8] states: 

1. If r If; e =>■ a then r lf b ™ e => a' where a' <b o . 

2. If r lh e <= v then r \^ h e <= v. 


Proof. Most cases of this lemma either follow by induction, or are analogous to 
the completeness lemma for System V. 


Case B Var 


x:a £ r 
r x => a 


Var 


Suppose a is for the form V{a}. v. Then we use a to instantiate the variables 
a. We know these a are not free in r by the Barendregt convention. It 
may be the case that generalization quantifies over more variables, i.e. a C 
a' = ftv{v) \ftv(r), leading to a more general result type. However, that is 
permitted by the statement of the theorem. 
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Case B Abs 


r, x:t 1^ e => v 
r ^ \x. e => r — ► v 


Abs 


The induction hypothesis gives us U, x:t ^ b " e => V{a}. v' where V{a}. v' <b 
v. Inverting \^ n gives us r, x:t lj b e => v' and inverting <b gives us 
v'\t/h\ <b v. We can then substitute and use SB_Abs to get r ly b Ax. e => 
r — > v'[t / a]. Generalizing, we get r \^ n Ax. e => V{a, a'}.r — > i/pf/a] 
where the new variables a ' come from generalizing r and the r' . We are 
done because (r -A v')\r /~a] <b r — > v and so V{a, a'}.r — > v' <b r — > v 
Case B App 


rkei 


Vi 


rk e i e 2 


r ^ e 2 


pi 


B App 


P2 


By induction we have r e± => a for some a <b v\ — > i> 2 . 

So by inversion cr = V{"a} , b.v[ — > v 2 , where (t>( — > v'^\f / b\ <b v± 
V 2 and v\ <b v' 1 ^r/~S\ [r'/fe] and P 2 f^/®] [^V&] — b v 2- 


V 6 . 


Also by inversion of [f b n , we know that T l^ b ei 
a are not free in r or e\. 

By substitution, we have W l^ b ei => V 6 . (v[ — > v' 2 )\f /a] 

And by SB_InstS, we have r ei =>• {v[ -A u^)[r/h1[r'/61. 


x >2 and that the 


By induction we have T fj b e 2 
e 2 <= v[ [t/ a] [?' /&]. 

So we can conclude r lj b ei e 2 < 

Case B Let 


v[ and by lemma 
v' 2 [t / a\[T' /b\. 


54 


we know that r (: b 


r lb ei => OT r, x:ai lb e 2 => a 

— — ; ; B Let 

r lb let x = ei in e 2 => a 


The induction hypothesis gives us T ^ b " ei => 
induction hypothesis also gives us r, x\o\ lf b " e 2 
Lemma 54 to get r,x:a[ 

Let 


with 


a 1 < b cti. 


The 


<72 with cr' 2 <b cr 2 . Use 


62 => o 2 where <j 2 <b cr 2 . 

a 2 =~V{&}. v where b = ftv(v)\ftv(r). Inverting l^ b " 
e 2 => v. We then use SB_Let to get r let x = ei in e 2 
gives us r ff b " let x = ei in e 2 => V{&}. u. 

Transitivity of <b (Lemma 25 1 gives us \/{b}.v <h mv 02 - 

Case B Int 


gives us r, x:a[ [f b 
=> v. Generalizing 


^b 


=> Int ~ 


B Int 


Trivial. 

Case B TApp 


r h t 

r h e => Va. v 

— — TApp 
r lb e @t =4> v[t / a\ 


The induction hypothesis (after inverting lf b ") gives us f | e A Ma.v 
where b = ftv(\/a.v') \ ftv(r) and v'[r/b\ <b v. Applying SB_TApp 


Visible Type Application (Extended version) 


61 


gives us r lj b e@T => v'[t/o\, and SB_Gen gives us r lf b ™ e@r => 
V{c}.u / [r/a] where c = ftv(v'[T/a\) \ ftv(r). We want to show that 
V {c} . v ' [t / a] <b u[r/a], which follows when there is some t' , such that 
v'[t / a]\f’ /c] <b v[r/a). 

This is equivalent to exchanging the substiution, i.e. finding a r' such that 
v’\t' /~c}[t / a\ <b v[rf a]. 

By Substitution (Lemma [23|, we have v'\r/b\ [t / a\ <b v[t / a]. We also know 
that the b are a subset of the c. So we can choose r' to be r for the b, and 
the remaining c elsewhere, and we are done. 

Case B Annot 


r ht v = Vo, b. (j) 
r,a\^ e (j) 
r 1^ (A a.e : v) => v 


Annot 


By induction, we have r, a \^ b e <= (f>. We can conclude by SB_Annot. 

Case B Gen 


r^e^a agftv(r) ^ 

r lb e =>■ V{a}. a 


Gen 


The induction hypothesis gives us T f^ b n e => a' where a' <b o. We know 
a' <b V{a}.cr. In other words, if a' = V{&}.tq and a = V{c}.u 2 , we have 
some r such that v\\f/b\ = u 2 ■ By the definition of <b we can use these 
same r to show that a' <b V{a, c}. w 2 . 

Case B Sub 


r ^ e => CTi cr x < b cr 2 0 
r ^ e => a 2 


Sub 


The induction hypothesis gives us r lf b " e => cr' where a' <b <ji. By transi- 
tivity of <b , we are done. 

Case B DAbs 


r, x:v\ lb e <= v 2 
r 1^ Xx. e <= v\ — > V 2 


DAbs 


By induction, we have that T, x:v\ 1^ b e <= u 2 . 

By inversion, we have prenex(v 2 ) = Vo. p and T, x:vi e <= p. 

Therefore by SB_DAbs, we can conclude r l^ b Xx. e Vi — 1 p, and by 

SB_DeepSkol, we know r lj b Xx. e <= iq — > u 2 . 

Case B DLet 


r lb e.\ => 0i 
r, a:: or fg e 2 <= ^ 
r let x = e± in e 2 <s= v 


DLet 


By induction we have T, x:<Ji l^ b e 2 <= v. Also by induction, there is some 
<j' <b ci, such that r lf b ” e => a' . By context generalization, we know that 
r, x:a[ l^ b e 2 <1= v. So we can use SB_DLet to conclude. 


62 Richard A. Eisenberg, Stephanie Weirich, and Hamidhasan G. Ahmed 

Case B Infer 


rh b e 


cr 1 


&1 <dsk t’2 


rh b e 


B Infer 


V2 


In this case, we know that o\ <dsk x> 2 - We would like to show that r l^ b e <= 
V 2 - Suppose prenex(v 2 ) = Va. p, by rule SB_DeepSkol, it suffices to show 
r tb e <= p. 

Suppose cr 1 is V{ b}.v\. By inversion of <j± <d s k y 2 , we know that v± [r'/ 6] <d s k 

P ■ 

By induction, there is some a' <b <Ji, such that F l^ b n e => cr' . By inversion 
of lf b " we know that a' is of the form V{a}. v' and that r e => v' . 

By inversion of a' <b <7i, we know that v'[r/a\ <b v±. By substitution, 
this means v' [r/a][r'/6] <b V\\f' /b\. By the Barendregt convention, the b 
can appear in the r but not in v' . So we can rewrite this substitution as 
/b\/n]. We can then substitute (as the a were generalized) r lj b e => 


v'[t[t' / b\/a\. 


By transitivity (Lemma 36 1 we know that v' [t[t ! / b\/ a] <dsk p. So we can 
conclude r e p using SB_Infer. 

Case B Skol 


rh b e 


v a £ ftv(r) 


F h b e 


Va. v 


B Skol 


v. We would like to conclude r b e 


By induction, we have r lf b e 
Va. v. By inversion, we have r lj b e <= p where prenex(v) = Va. p. However, 
this means that prenex(\/a.v) = Va,a. p. Therefore, we can conclude using 
SB DeepSkol. 


Unlike System V, we have not shown that the algorithm determined by Sys- 
tem SB computes principal types. We believe that all of the complexities of that 
proof are already present in the corresponding proofs about System V and the 
extensive proofs for the bidirectional type system of GHC |26| . 
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H Higher-rank systems: OL variant 


This section concerns the properties of a higher-rank type system that does not 
include deep skolemization and provides an alternative treatment of scoped type 
variables. 

We present this system mainly for comparison with Dunfield/Krishnaswami m 
(see below). However, it also shows that the deep-skolemization relation is not 
an essential component of our type system. Instead of <dsk, it uses the Odersky- 


Laufer subsmption relation shown in Figure 13 


The only difference between this system and the DSK version of System B, 
is the use of this relation in the B_ Infer rule and the treatment of scoped 
type variables in the B_Annot and B_Skol rules. See Figure [l4| The syntax- 
directed version of the system is in Figure [T5| It differs from System SB in that 
it again uses the < 0 | relation, introduces scoped type variables at SB_Skol and 
does not do deep-skolemization in the checking rule for polytypes. 


A note on scoped type variables The alternative mechanism for scoped type 
variables leads to some “strange” binding behavior. In particular, if y has the 
following type in the context 

y : (Va. a — > a) — » Int 


then the expression 


y ( Ax . ( x : a)) 


would be well typed, even though the specification of j/’s type could be very far 
from this application. Likewise, we only introduce top-level variables into scope. 
In particular, 

(Ay. Ax. (x : a) : Int — » Va. a — > a) 


would be well-typed if we introduced scoped type variables in rule B_Skol, but 
is rejected by system B. 


V\ < 0 I v 2 


OL B ARefl 

T <ol T 


V 3 <ol Vl V2 <ol V 4 ^ 

OL B AFun 

VI -> V2 <ol v 3 -> V4 - - 


01 [r/a] <01 <t >2 b ftvtya.fa) 
Va. 0i < 0 i V6. 02 


OL B AInstS 


Fig. 13. Subsumption in the Odersky-Laufer type system 
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E b e 4= v \ 


Synthesis rules for System B 
x:a G E 


OL B Var 


F b x => a ~ ~ 


E, x:t ^ e =4- v 
F Ij; Ar. e r -> u 


-OL B Abs 


F ^ e i => ui — > U2 E e2 4= vi 
E ^ e i e 2 => V 2 

F ^ ei =£■ cti E, x:a i ^ e 2 =4 a 


OL B App 


E L let x = ei in ei =4 a 


OL B Let 


OL B Int 


F b n =4 !nt ~ ~ 


F b r E ^ e => Va. u 
E ^ e @r =>- u[r/a] 

Fhw Llf e<^w 


-OL B TApp 


E ^ (e : v) =4 u 

E ^ e => cr a ^ ftv(r) 
E ^ e=^V{a}.a 

E ^ e =4 <ji oi < b as 
E L e => (T 2 


OL B Annot 


OL B Gen 


OL B Sub 


E, x:vi ^ e <J= % 

E t Ax. e 4= Vi — > V 2 


OL B DAbs 


E ^ ei => ei E, ®:<ti e 2 4= v 
F ^ let x = ei in e 2 4= v 

r,a^ e 4= v a g ftv(F) 


OL B DLet 


E ^ e 4= Vo. v 


E hr e => 1>i Vl <ol V 2 


F b e 4= V 2 


OL B Skol 


OL B Infer 


Fig. 14. Declarative specification of System OL-B 
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\ r kb e- 


r, x-.T 4 e => v 


OL SB Abs 


P 4 Xx. e => r — > v ~ 


OL SB Int 


P Lb n => Int ~ — 


r kb e => V a . 0 
no other rule matches 
P lib e => 0[r/a] 


-OL SB InstS 


®:V{a}. v £ P 


OL SB Var 


P 4 * => v[r/a] 

P 4 ei => vi — > v 2 r 4 e 2 <= vi 
P 4 ei e 2 => v 2 

r 4" ei <7i r, x\ai 4 e 2 =>■ v 2 
P 4 let x = ei\ne 2 => v 2 

P h r P 4 e =► Va. v 


OL SB App 


OL SB Let 


P 4 e @r =*• t>[r/a] 

ri-« p 4 e **= 

rif b (e : w) =» u 


OL SB TApp 


-OL SB Annot 


p la, e => 4> 

no other rule matches 


r 4 e; 


-OL SB Phi 


T 4" e =$■ a 


a = ftv{v)\ftv{r) P 4 e => u 
Plf b " e => V{a}. v 


OL SB Gen 


P lib e -4= 0 


r, x:vi 4 e 4= v 2 
P 4 Xx. e 4= vi — > v 2 


OL SB DAbs 


P 4" ei => ai P, x:ai 4 e 2 4= (j> 2 
P 4 let x = ei in e 2 4= <j> 2 


OL SB DLet 


P 4 e =t W vi <oi 02 
no other rule matches 

P 4 e 4= 02 


-OL SB Infer 


P 4 e 4= u 


P, a 4 e -4= 0 a 0 /tn(P) 


r 4 e 4= Va. < 


OL SB Skol 


Fig. 15. Syntax-directed specification of System OL-SB 
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H.l Properties of OL subsumption 

Lemma 42 (Substitution). If V\ < Q | r; 2 then S(v 1) < 0 i S(v 2). 

Proof. Vytiniotis et al., Lemma 2.1 (PSj) 

Lemma 43 (Reflexivity for < Q | ). For all v, v < 0 | v. 

Proof. Vytiniotis et al., Lemma 2.2 (PEj) 

Lemma 44 (Transitivity for < Q | ). If v \ < 0 i t >2 and V2 < 0 i V3, then v± < 0 i V3. 
Proof. Vytiniotis et al., Lemma 2.3 (|26j) 

Lemma 45 (Single skol admissible). If v± < 0 i i >2 then v\ < 0 i Vc.-u 2 (when 
c is not free in v\). 

Proof. Proof is by induction on v\ < 0 i V2- 

Lemma 46 (Monotypes are instantiations). If v < 0 i r then v <b r. 

Proof. Proof is by induction on v < 0 i t. In each case the result holds directly by 
induction. 

Lemma 47 (Subsumption contains instantiation). If v \ <b v 2 thenv 1 < 0 i 
V 2 - 


Proof. Proof is by induction. 


Case B 
Case B 
Case B 


Refl: Trivial 
Fun: By induction. 
InstS: 


<t>i[r/b] <b 
Va, b. <b Va. 


InstS 


By induction we know that (t>\ [t/6 ] < Q | fa. We can rewrite this as 
(f>i[d /a\[r / b] < Q i fa, and conclude by DSK_Inst. 


Lemma 48 (Transitivity of Higher-Rank subsumption I). If v\ <b V2 

and V2 < 0 i V3, then v± < Q i '^3- 


Proof. Follows from Lemmas [44] and |47| 

Lemma 49 (Transitivity of Higher-Rank subsumption II). If v 1 < 0 | V2 

and V2 <b V3, then V\ < 0 i V3. 

Proof. Follows from Lemmas [44] and [47] 
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H.2 Substitution 

Lemma 50 (Substitution for System B). Assume that the domain of S is 
disjoint from the variables of T or the free type variables of e. 

1. If r 1^ e =>■ a then r e =>• S(a) 

2. If r e <= v then r ^ e <= S(v) 

Lemma 51 (Substitution for System SB). Assume that the domain of S is 
disjoint from the variables of T or the free type variables of e. 

1. If r h^ b e =>■ cf> then T e => S(4>). 

2. If r \^ h e => v then r lf b e => S (v ) . 

3. If r \^ b n e => a then r \^ b n e => S(a). 

4- If r^ h e<=v then r\ ^ e <= S(v). 

5. If r \j h e <= (f> then r \^ b e <= S (0 ) . 


t then f ^ e 


T. 


H.3 Other properties 

Lemma 52 (Monotypes are uninformative). ifr\- b 

Proof. This follows because of the four checking rules, the first two have identical 
monotype versions, the third doesn’t apply to monotypes and the last follows 
by B_Sub and the fact that r is an instantiation of a (lemma 46 1 . 


H.4 Soundness of System SB 
Lemma 53 (Soundness of System SB). 

1. If r e => <j> then T 1^ e => 0. 

2. If r \^ b e => v then r e =>■ v. 

3. If r \f b n e => a then T 1^ e => a. 

4 ■ If r \^ b e <= v then r e <= v. 

5. If r \i b e <= (j> then r e <= f>. 

Proof. Most of the cases of this lemma follow via straightforward induction. 
Cases SB_Spec, and SB_Var are similar to the cases for V_InstS and 
V_Var. ' 

Case SB Infer: 


r Ifb e => V! VI <ol 0 2 

no other rule matches 
r tb e 4= 0 2 


OL SB Infer 


By induction, we know that r 1^ e =>■ v\. We can show that r e <= 0 2 by 
B_Infer. 

Case SB Skol 


f, a ^ e a ^ ftv(r) 

r £ b e 4= Va. 0 


OL SB Skol 


By induction, we have r e 4= p. We can immediately use rule B_Skol to 
conclude. 
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H.5 Completeness of SB 

Generalizing and specializing syntax- directed derivations 

Lemma 54 (Context Generalization). Suppose r' <b r 

1. If r e => <f> then there exists <f> <b <f> such that r' e => <f>' . 

2. If r \^ b e => v then there exists v' <b v such that A' | b e => v' . 

3. If r | b ™ e => a then there exists cr' <b cr such that F' K' 1 e =$■ a' . 

4. If r \^ b e <= v and v <b v' then r' \f b e <= v' . 

5. If r [jb e <= (f> and f> < b then r' Ijb e 4= </>. 


Proof. Proof is by induction on derivations. 


Case SB Abs: 


r, x:t | b e => v 
r Ijb Xx. e =r* t — ^ v 


OL SB Abs 


By induction, we know that T 7 , x:t | b e => v' for v' <b v. Therefore, 
r' Xx. e=iT-iw' and, by SB_Fun, r — > v' <b r — > v. 

Case SB Int: 


Trivial. 

Case SB InstS: 


r kb n => int 


OL SB Int 




e => Va. <f> 
no other rule matches 


rb 


sb ^ 


<t>[r/ a) 


OL SB InstS 


By induction, we know that T | b e =t> r/ where v' <b Va. <j). By inversion, 
we know that v' must be of the form Va,b.<j>' where <j>'\7 , /b\ <b 4>- By 
SB_InstS, we can conclude T | b e => (<// [t' / b])[T / a\. We also need to 
show that (<// [r 7 / 6 ])[t / a] <b </>[r/a], which follows by substitution (Lemma 


231. 


Case SB Var: 


*:V{a}. v £ T 
u[r/a] 


rkb 


OL SB Var 


We know that x:cr £ T, where cr <b V{a}.u. So by i nve rsion, cr must be 
\/{b}.v' such that v'\f'/b\ <b v. Therefore, by lemma 23 v'[t' / b][r/a\ <b 


u[r/a]. As we know that the a are not free in v', we can rewrite the left 
hand side as: t/pf / [ ; f/a]/&], and choose those types in the use of SB_Var. 

Case SB App: 


r ^b ei => Vi -> v 2 r 4 e 2 <= Vi 
r 4 ei e 2 => v 2 


OL SB App 


By induction we have r' kb e i => (j> such that </> <b v\ — > v 2 . By inversion, 
this means that <j> must be of the form v\ — > v 2 where v\ <b v[ and v' 2 <b w 2 . 
By induction, we have r' | b e 2 4= u([r/&]. So we can conclude by SB_App. 


Visible Type Application (Extended version) 


69 


Case SB Let: 


r lf b " ei => fJi r, X\CJI 4 e 2 => v 2 
r lj b let X = ei in e 2 =*> v 2 


OL SB Let 


By induction r' lf b " ei => a' x for a' x <b o\. By induction (again), T', x:a[ lj b 
e 2 => v 2 for v' 2 <b v 2 - So we can conclude by SB_Let. 

Case SB TApp: 


rhr r lf b e =► Vo. v 
r b e @r => v[t / a\ 


OL SB TApp 


By induction r' f^ b e => v' where v' <b Va. v. By inversion, v' is of the form 
Va.Pi where v\ <b«. By substitution, v\[t / a] <b v[t/o\. 

Case SB Annot: 


r \- v 

r 4 (e : v) => v 


OL SB Annot 


Holds directly by induction. 

Case SB Phi: 


r lib e => </> 
no other rule matches 




-OL SB Phi 


Holds directly by induction. 

Case SB Gen: 


a 


ftv(v)\ftv(r) 

j-i |^en 




V{a}. . 


-OL SB Gen 


By induction, we have 7^' l^ b e v' for v' <b v. Let b = ftv(v r ) \ vars(r). 
We want to prove that Vj &}• v' <b Vial. v. This holds by definition. 

Case SB DAbs: 


r, xwi 4 e 4= v 2 
r Ijb Xx. e <= v\ — > v 2 


OL SB DAbs 


Let r' <b r and v\ — > v 2 < b v' be arbitrary. By inversion, we know that 
v' is v[ — »• v' 2 where v[ <b V\ and v 2 <b v 2 . By induction, we know that 
r' ,x:v[ l^ b e v 2 . So we can conclude by SB_DAbs. 

Case SB Infer: 


r 4 e => Pi Vi <oi 
no other rule matches 


r b 


sb ^ 


<^2 


-OL SB Infer 


Let r' < b r and (f> 2 <b 4>' be arbitrary. By induction, we know that r' l^ b 
e => v' for v' <b v\. We want to show that v' < 0 i <f>' ■ This holds by lemmas 48 
and 091 
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Case SB DLet: 


A (f b " e x =>■ ax r, x:ax lib e 2 f> 2 
r ^ let x = ex'in e 2 <= (f 2 


OL SB DLet 


Let A' < b A and <b <t>' be arbitrary. By induction, we have A' tf b ” 
ei => a'x for a\ <b a i. By induction (again), r',x:a[ lj b e 2 <= (f> . So we can 
conclude by SB_DLet. 

Case SB Skol: 


A, a lit, e 4> a fL ftv(r) 

r 4 e <*= vs. 0 


OL SB Skol 


Let A' <b r be arbitrary. Result holds by directly by induction and 
SB Skol. 


Completeness theorem 

Lemma 55 (Completeness of System SB). 

1. If r 1^ e => a then r tf b " e => a' where a’ <b a. 

2. If r 1^ e <= u then r (f b e <= v. 


Proof. Most cases of this lemma either follow by induction, or are analogous 
to the completeness lemma for System V. We discuss the most novel cases are 
B_App, B_Annot, plus the checking rules. 


Case B Var 


x:a £ r 
F lb x => a 


OL B Var 


Let a be V{a}. v. We can use the types a to instantiate the variables a. We 
know these a are not free in A by the Barendregt convention. It may be 
the case that generalization quantifies over more variables, i.e. a C a' = 
ftv(v) \ vcn's(r), leading to a more general result type. However, that is 
permitted by the statement of the theorem. 

Case B Abs 


A, x:t lb e => v 
r ^ Xx. e => r — > v 


OL B Abs 


The induction hypothesis gives us A, x:t l^ b " e => V{«}. v’ where V{a}. vf <b 
v. Inverting gives us A, x:t l| b e => v' and inverting <b gives us 
v'\f/~a] <b v. We can then substitute and use SB_Abs to get A Xx. e => 
t — > v'\f/a\. Generalizing, we get A 1^™ Xx. e => V{a, o'}.r — > v'\r/a\ 
where the new variables a '! come from generalizing t and the r. We are done 
because (r t/)[r/a] <b r — >• and so V{o, a'}. 
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Case B App 


r ^ e i => ti -> v 2 r e 2 <= V\ 

r ^ ei e 2 => v 2 


OL B App 


By induction we have r If™ e\ => a for some er < b v\ — > v 2 . 

So by inversion a = V{h}, b.v[ — )• v 2 , where {v^ — > v' 2 )[r/h][r , /&] <b v± — > 
v 2 and Vi <b v[ [r/o] [r'/fr] and ^[T/a^r'/fr] — b ^ 2 - 

Also by inversion, we know that T f b ei =>■ V&.u^ -> i >2 and that the a are 
not free in T or ei. 

By substitution, we have r f b ei => V6. — ► u 2 )[t/'o] 

And by SB_InstS, we have T f b ei =>■ (v[ — > pQ[t/o][t / /&]. 

By induction we have T f b e 2 <= v [ and by lemma |54| we know that r f b 
e 2 <= v[[t / a][¥ /b]. 

So we can conclude r f b ei e 2 <= u 2 [t/o][t / /&]- 

Case B Let 


U f ei => ay r, x:ai f e 2 
r 1^ let x = ei in e 2 => a 

The induction hypothesis gives us T f 
induction hypothesis also gives us r,x:<j\ f 


-OL B Let 


en 

sb ei => 

en 

sb e 2 


Lemma 54 to get r,x:a[ f™ e 2 =>■ a 2 where a 2 <b u 2 - 


with er( <b <J\. The 
er 2 with a' 2 <b cr 2 . Use 


Let a 2 = V{fc}.u where b = ftv(v ) \ vars(r). Inverting f 


r, x:a[ f b e 2 => v. We then use SB_Let to get r f b let x = ei in e 2 
Generalizing gives us r f™ let 2 = ei in e 2 => V{&}. v. 

Transitivity of <b (Lemma 25 1 gives us V{6}.u <hmv cr 2 . 

Case B 


sb" gives US 
v. 


INT 


Trivial. 

Case B TApp 


r k n 


Int 


OL B Int 


fhr 


rb b e 


Vo. v 


Tf e @r : 


v[t/ a] 


OL B TApp 


The induction hypothesis (after inverting f™) gives us r f b e => Vo. i/, 
where b = ftv(\/a.v') \ vars(r) and v'[T/b\ <b v. Applying SB_TApp 
gives us r f b e@r => v'[t/o\ , and SB_Gen gives us T If™ e@r => 
V{c}.i/[t/o] where c = ftv{v'[r / a]) \ vars(r). We want to show that 
V{c}. v'[t/o\ <b v[r/a\, which follows when there is some r', such that 
v'[t/ a]\f' /~c] < b v[t/o\. 

This is equivalent to exchanging the substiution, i.e. finding a t' such that 


v'[t' / c}[t / a] <b v[t/cl\. 


By Substitution (Lemma 23 1, we have v'\f/b][T/a\ <b v[t / a}. We also know 
that the b are a subset of the c. So we can choose r' to be r for the &, and 
the remaining c elsewhere, and we are done. 
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Case B Annot 


r \- v r e <= v 

r 1^ (e : v) => v 


OL B Annot 


The induction hypothesis gives us -T Ig e <= v, so the result immediately 
follows. 

Case B Gen 


r e => (j a qL ftv(r) 
r e => V{a}. a 


OL B Gen 


The induction hypothesis gives us r f^ b " e => a' where a' <b o. We know 
a' <b V{a}.o\ In other words, if a' = V{6}.t>i and er = V{c}.u 2 , we have 
some t such that v x [r/b] = v 2 . By the definition of < b we can use these 
same r to show that a' <b V{a, c}. u 2 . 

Case B Sub 


r e => CTi O'! <b cr 2 
r ^ e => <72 


OL B Sub 


The induction hypothesis gives us r ^ b ™ e => o' where o' <b or. By transi- 
tivity of <b , we are done. 

Case B DAbs 


r, x:vi ^ e <= v 2 
r Xx. e <= Vi — > V 2 


OL B DAbs 


By induction, we have that r,x:v 1 lj b e v 2 . Therefore by SB_DAbs, we 
can conclude T Xx. e V\ — ► u 2 . 

Case B DLet 


r ^ d =>■ o'! r, auor ^ e 2 -4= u 
T ^ let a; = e x in e 2 <= v 


OL B DLet 


By induction we have T, x:a x e 2 <= v. Also by induction, there is some 
a' <b o'!, such that T ^ b " e => a'. By context generalization, we know that 
r, x:a[ l| b e 2 v. So we can use SB_DLet to conclude. 

Case B Skol 


r, a e <= v a ^ ftv(r) 
r \ b e <= Va. v 


OL B Skol 


By induction, we have r, a \f h e <= v. We can conclude using SB_Skol. 
(Actually, first inverting and then potentially applying SB_Skol multiple 
times). 

Case B Infer 


r fh e => u 1 Vi < 0 | v 2 

r^e<=v 2 


OL B Infer 
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By induction, there is some o' <b Vi, such that r If, " e 


o'. By inversion 
v' , where 

a do not appear in e and r. 

By inversion of <b , we know that v'[r/a \ <b V\. By substitution, we know 


sb 

of we know that o' is of the form V{a}. v' and that r fj: b e 


that r \^ h e 


v'[t / a]. 


By transitivity (Lemma 48 ) we know that v'[t / a] < 0 i v 2 ■ So we can conclude 
using SB_Infer. 


H. 6 Comparison with Dunfield / Krishnaswami 

The presence of the non-deep-skolemization System B, makes it easy for us 
to compare our type system with the system designed by Dunfield and Krish- 
naswami. (We refer to this system as DK in the following.) In particular, we can 
show that our system subsumes the DK system. 

Suppose r I ~dk vi ^ V2 is the subtyping relation from the DK paper, Figure 

I . 

Lemma 56 (Higher-rank subsumption contains DK subtyping). If 

r \~dk Vi < v 2 then v\ < Q i v 2 . 

Proof. But induction on the DK subtyping judgement. 

Case DeclsjVar Immediate from DSK_Refl. 

Case Decl^Unit Immediate from DSK_Refl. 

Case Decl^— > Directly via induction and DSK_Fun. 

Case Decl^ VL By induction and DSK_Inst. 

Case Decl^ VR By induction and DSK_Inst. 

The DK system includes an application judgement, written r I ~dk v 1 o e => 
=> v 2 , which means "applying a function of type Vi to e synthesizes type v 2 ". 

Our declarative system does not need this judgement because we allow im- 
plicit instantiation for specified polytypes. In our system, the rule B_Sub allows 
instantiation at any point in the judgement. However, in the DK system, instan- 
tiation is restricted to be immediately before an application or when synthesis 
mode and checking mode meet (via subtyping) . This is what our algorithm actu- 
ally does, but because we have the instantiation relation, our declarative system 
need not make this constraint. 

Lemma 57. If r \~dk v\o e =!=> v 2 then there exists some v[ such that V\ <b 
v[ — » v 2 and r b dk e <= v[. 

Proof. Proof is by induction on the judgement. It requires an observation about 
our instantiation judgement that if V\ <b v[ —¥ v 2 and m is V6. p, then we must 
have instantiated all of the b in the judgment. In otherwords, that p[r/b\ = 
v[ — >• v 2 . 

Now let r I ~dk e => v, T I ~dk e 4= v be the judgements shown in Figure 4 
of their paper. We can also argue that System B can typecheck the same terms. 
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Lemma 58. 

1. If r I ~dk e <= v then T ^ e 4= v. 

2. If r I ~dk e =$■ v then r ^ e => v. 

Proof. Proof is by induction on derivations. Most cases have direct analogues in 
System B. Note that technically we replace their unit type with int. They view 
the checking rule for the unit value as primitive and add a synthesis rule for 
convenience. Our system does not have a checking rule for constants, but can 
derive one from the synthesis rule and B_Sub. 

The only other case that requires additional reasoning is the convenience 
rule for inferring the types of functions. We need to use lemma [52] to convert a 
checking judgement for monotypes into a synthesis judgement. 


